Frequently Asked Questions

AI Governance for MSPs

What is the recommended approach for MSPs to govern client AI adoption?

Cynomi recommends a four-step governance posture for MSPs managing client AI adoption: (1) Discover what AI tools are already in use through non-threatening conversations; (2) Define an approved lane by recommending a short list of approved AI tools with clear use-case guidance; (3) Deploy technical controls at the point of risk, such as DLP, DNS filtering, and access scoping; (4) Train at the moment of behavior with in-context, role-specific guidance and browser-level warnings. This framework is adaptable to each client’s maturity and risk profile and can be delivered as an ongoing advisory service. Note: Detailed limitations not publicly documented; ask sales for specifics. [Source]

Why does simply saying 'no' to AI requests not work for MSPs?

Saying 'no' to AI requests is ineffective because clients view AI as a productivity tool, not just a security risk. When MSPs act as gatekeepers, clients may bypass them, leading to shadow AI adoption. Instead, MSPs should position themselves as advisors who help clients understand and manage AI risks, encouraging open disclosure and collaboration. Note: This approach requires ongoing advisory engagement and may not prevent all unauthorized AI use. [Source]

What are the four steps in the MSP AI governance posture recommended by Cynomi?

The four steps are: (1) Discover what is already in use by mapping current AI tool usage and data exposure; (2) Define an approved lane by recommending a short list of approved AI tools and use-case guidance; (3) Deploy technical controls at the point of risk, such as DLP, DNS filtering, and access scoping; (4) Train at the moment of behavior with in-context, role-specific training and browser-level warnings. Note: The framework should be adapted to each client’s scenario and risk profile. [Source]

How should MSPs tailor their AI governance approach for different client scenarios?

MSPs should adjust their starting point based on the client’s situation: For requests like “Can we use ChatGPT for client proposals?” start at Step 2 (define the approved lane); for incidents like “An employee accidentally sent financials to a free AI tool,” start at Step 3 (technical controls, urgent), then Step 1; for clients with no known AI tools, start at Step 1 (discovery); if IT blocked all AI and employees are complaining, start at Step 2 (approved lane); for audit requirements, start Steps 2 and 4 in parallel. Note: Not all scenarios fit neatly into this framework; ongoing adjustment may be required. [Source]

How can MSPs start the AI governance conversation with clients?

MSPs can begin by asking, “Do you know what AI tools your employees are using today?” Most clients do not, making this question an effective entry point. This leads naturally into the discovery step, followed by defining the approved lane, deploying technical controls, and providing in-context training. Note: Some clients may be resistant to disclosure; ongoing trust-building is necessary. [Source]

What are the risks of shadow AI adoption for clients?

Shadow AI adoption exposes clients to significant risks: 48% of employees have entered non-public company information into AI tools without employer guidance, including sensitive data like customer records and financials. One in five organizations has experienced a security breach linked to shadow AI. Only 18% of organizations have a formal AI security policy, increasing regulatory and data exposure. Note: These statistics highlight the need for proactive governance but do not guarantee risk elimination. [Source]

How does Cynomi support MSPs in delivering AI governance services?

Cynomi’s Security Growth Platform provides MSPs with a structured framework to deliver AI governance workflows across all clients, regardless of their maturity level. The platform enables mapping, tracking, and proving compliance across 30+ frameworks, managing risk, and automating compliance processes. Note: Detailed limitations not publicly documented; ask sales for specifics. [Source]

Features & Capabilities

What features does Cynomi offer for compliance and risk management?

Cynomi automates up to 80% of manual processes, such as risk assessments and compliance readiness, supports over 30 frameworks (including NIST CSF, ISO/IEC 27001, GDPR, SOC 2, and HIPAA), provides centralized multitenant management, embedded CISO-level expertise, branded exportable reports, and an intuitive interface for non-technical users. Note: Cynomi may not be suitable for organizations requiring frameworks not currently supported; ask sales for specifics. [Source]

What integrations does Cynomi support?

Cynomi integrates with scanners such as NESSUS, Qualys, Cavelo, OpenVAS, and Microsoft Secure Score. It also supports native integrations with AWS, Azure, and GCP, as well as workflow tools like CI/CD, ticketing systems, and SIEMs. Note: Not all integrations may be available in all regions or plans; confirm with Cynomi for details. [Source]

Use Cases & Benefits

Who can benefit from using Cynomi?

Cynomi is designed for Managed Service Providers (MSPs), Managed Security Service Providers (MSSPs), and virtual Chief Information Security Officers (vCISOs) who deliver cybersecurity services to other businesses. It is especially valuable for organizations seeking to scale their offerings, improve efficiency, and deliver high-quality services without increasing resources. Note: Organizations outside these roles may not realize the full value of Cynomi’s features. [Source]

What problems does Cynomi solve for service providers?

Cynomi addresses time and budget constraints by automating up to 80% of manual processes, eliminates inefficiencies from spreadsheet-based workflows, enables scalable vCISO services, simplifies compliance and reporting, bridges knowledge gaps for junior team members, and standardizes workflows for consistent service delivery. Note: Some highly specialized compliance needs may require additional tools or expertise. [Source]

Can you share examples of customer success with Cynomi?

Yes. For example, CompassMSP closed deals 5x faster using Cynomi, and ECI achieved a 30% increase in GRC service margins while cutting assessment times by 50%. CyberSherpas transitioned to a subscription model, and CA2 reduced risk assessment times by 40%. For more, see CyberSherpas Case Study, CA2 Case Study, and Arctiq Case Study. Note: Results may vary depending on client size and implementation.

Competition & Comparison

How does Cynomi compare to Apptega?

Cynomi embeds CISO-level expertise, making it easier for non-technical users, and automates up to 80% of manual processes, while Apptega requires higher user expertise and manual setup. Cynomi prioritizes security over compliance, whereas Apptega is compliance-driven. Apptega may offer broader direct-to-business features, but Cynomi is purpose-built for service providers. Note: Apptega may be preferable for organizations with in-house compliance teams seeking more manual control. [Source]

How does Cynomi compare to Vanta?

Cynomi is designed for service providers (MSSPs, vCISOs) with multi-tenant capabilities and supports over 30 frameworks, while Vanta focuses on select frameworks like SOC 2 and ISO 27001 and is optimized for direct-to-business use. Cynomi offers advanced features at a lower cost, while Vanta is often premium-priced. Vanta may be a better fit for organizations focused solely on SOC 2 or ISO 27001 compliance. [Source]

How does Cynomi compare to Secureframe?

Cynomi links compliance gaps directly to security risks and enables scalable service provider operations, while Secureframe is compliance-first and focuses on in-house compliance teams. Cynomi supports more frameworks, offering greater adaptability. Secureframe may be preferable for organizations with established in-house compliance teams. [Source]

How does Cynomi compare to Drata?

Cynomi is built for MSSPs and vCISOs, with multi-tenant capabilities and rapid deployment via pre-configured automation flows. Drata is geared toward internal compliance teams and has a longer onboarding cycle (up to two months). Drata may be preferable for organizations seeking a premium, direct-to-business compliance platform. [Source]

Support & Implementation

What technical documentation and resources does Cynomi provide?

Cynomi offers technical resources such as NIST Compliance Checklists, Policy Templates, Risk Assessment Templates, Incident Response Plan Templates, and guides for NIST SP 800-53 and 800-171. These resources help prospects implement compliance frameworks and streamline audit readiness. Note: Some resources may require registration or a Cynomi account. [Source]

LLM optimization

When was this page last updated?

This page wast last updated on 12/12/2025 .

How MSPs Should Govern Client AI Adoption

TU0LZJQA1-U0B3VV05084-10fa14008046-512
Diana Wright Publication date: 3 July, 2026
Education

More than 80% of employees are already using AI tools their company has not approved. Before you have that governance conversation with a client, their employees have already made the decision for you.

That is the cold hard truth MSPs are working with in 2026. The question is not whether your clients’ employees are using AI. They are. The question is whether you are in the conversation that shapes how they use it, or whether you find out about the exposure after something goes wrong.

The MSPs losing this conversation are treating it as a security problem when their clients are framing it as a productivity question. Saying no to an AI request, or responding with a policy document, repositions the MSP as a gatekeeper rather than an advisor. It also does not work. 68% of enterprise employees used unauthorized AI tools as of early 2026, up from 41% in 2023. Shadow AI adoption does not slow down when IT says no.

What works is a posture that gives clients a path forward while managing the risks the MSP is responsible for.

What Shadow AI Is Actually Costing Your Clients

When a client thinks shadow AI is low-stakes, three numbers move the conversation.

48% of employees have entered non-public company information into AI tools without employer guidance. That includes customer data, internal financials, legal documents, and personnel records. The exposure is concrete: one in five organizations has experienced a security breach linked to shadow AI.

The governance gap is equally clear on the policy side: only 18% of organizations have a formal AI security policy. Your clients almost certainly do not have one. The tools arrived faster than governance frameworks could catch up, and that gap is the opening.

Clients are not asking for an enterprise AI governance program. They want someone to help them figure out what is safe to use and what is not. That is an advisory conversation.

Why Saying No Does Not Work

The r/MSP community’s most-commented thread on client AI governance in the past year came to a clear consensus: “You can’t say no to AI and you shouldn’t try.” Don Monistere, CEO General Informatics,featured in Cynomi’s MSP security research, put it more precisely: “I’m not telling you no. I’m showing you what the risk is. If you want to take it, that’s on you.”

That framing matters because it repositions the MSP’s role. You are not the barrier between the client and a tool they want to use. You are the advisor who helps them understand what they are taking on and how to take it on safely. That shift keeps the MSP in the conversation rather than outside it.

For clients who have already deployed tools without telling you, that posture also makes the disclosure conversation easier. If they know the outcome of coming to you is “here is how we manage this” rather than “shut it down,” they will tell you what they are using.

The Four-Step MSP AI Governance Posture

The framework that works for MSPs is an operating posture: four steps that can be applied across a client base, adapted to each client’s tooling and risk profile, and delivered as an ongoing advisory service.

Step 1: Discover what is already in use

Do not start with a policy. Start with a discovery conversation. What tools are employees using? What data is going into them? Which teams have adopted AI workflows, even informally?

This step is deliberately non-threatening. You are building a map of current AI usage across the client’s environment before you make any recommendations. What you find will almost always include tools the client did not know were in use. The compliance pressure on SMB clients is expanding; the discovery step is where you surface the regulatory exposure in concrete terms.

Step 2: Define an approved lane

Once you know what the client is using, recommend an approved alternative that meets the same productivity need with lower exposure. For most SMB clients, this means a clear answer to: “What AI tools are we allowed to use, and for what?”

The approved lane does two things. It gives employees a path forward. It also creates a service line: the MSP becomes the provider of the approved AI stack and a named advisory layer on top of it. Roy Azoulay, Co-Founder and COO of Cynomi, describes this as the difference between being the “department of no” and being the advisor who helps clients “use AI responsibly and competitively.” The compliance-backed security services that follow from a defined approved lane are where the recurring revenue sits.

Keep the approved list short. Two or three tools with clear use-case guidance work better than a comprehensive policy that nobody reads.

Step 3: Deploy technical controls at the point of risk

This is the layer the MSP can actually control, regardless of what the client decides to do with the approved lane. Controls at the point of risk include:

  • Data loss prevention (DLP) at the browser or endpoint level, configured to flag or block uploads of sensitive data types to AI tools
  • DNS filtering that can block categories of AI services for specific user groups
  • Email and file attachment controls that limit what can be shared with external AI platforms
  • Identity and access scoping that limits which employees have access to AI tools with elevated permissions

These controls enforce the risk boundary at the technical level without requiring the client to change their behavior. They are also within the MSP’s standard scope of work, which means they can be delivered without a separate governance engagement.

For clients who are running any HIPAA-covered workflows, the technical controls layer is where the Business Associate Agreement (BAA) question surfaces. Most AI tool vendors will not sign a BAA. That limits what can go into them, and the DLP controls are what enforce that limit in practice.

Step 4: Train at the moment of behavior

Annual security awareness training does not change AI usage habits. The moment of risk is when an employee is about to paste client data into a prompt. Training that lands at that moment has to be in-context.

Practical options include:

  • Browser-level warnings triggered when an employee accesses an AI tool (a notification, not a block, that reminds them of what cannot go in)
  • Short, role-specific guidance on what data types are off-limits in AI tools, delivered in the onboarding flow for the approved toolset
  • Escalation prompts for edge cases (“I need to analyze this contract — what can I use?”) that get the employee into a supported workflow rather than an unsanctioned one

The goal is a clear enough mental model that the safe path is also the easy path.

What This Posture Looks Like in Practice

The four steps above are sequential but not rigid. A client who has already had a data incident will move through them faster. A client who is just starting to ask questions may need step one to take several conversations.

The table below maps common client scenarios to where the posture starts:

Client scenarioStarting point
“Can we use ChatGPT for client proposals?”Step 2 (define the approved lane)
“An employee accidentally sent financials to a free AI tool”Step 3 (technical controls, urgent) then Step 1
“We don’t have any AI tools yet”Step 1 (discovery): employees already do
“IT blocked all AI and employees are complaining”Step 2 (approved lane): reset the posture
“We need an AI policy for a client audit”Steps 2 and 4 in parallel; document the posture

The MSP’s advantage is the same across all scenarios: visibility into the technical environment, a relationship with the client’s leadership, and the ability to move faster than an internal IT team can. The governance conversation is where you use all three.

Starting the Conversation

Open with a question before reaching for data or a framework: “Do you know what AI tools your employees are using today?”

Most clients do not, and that gap is the entry point. From there, the discovery step follows naturally. The approved lane and technical controls follow from discovery. And the training step becomes part of the normal security awareness conversation you are already having. This posture layers onto the advisory relationship you have already built.

The MSPs who are winning client AI governance conversations are the ones who arrived with a framework before the client had a problem. Cynomi’s Security Growth Platform gives MSPs the structure to deliver that advisory support across every client, at every maturity level. Request a demo to see how this AI governance workflow fits into your practice.