This article is written by Brad Gross, who is founder and president of the Law Office of Bradley Gross, P.A., a business technology law firm.

If you’re an MSP owner, expanding your services to include strategic technology advice can be a financial game changer. By offering guidance on business decisions, recommending platforms, and helping clients adopt AI, you transform from a traditional IT solution provider to a trusted business advisor—a position that demands a financial premium.

But there’s a catch. As soon as you start giving strategic advice, your legal risks change. Clients stop seeing you as an IT troubleshooter and start thinking of you as the company responsible for all their technology and service-related outcomes.

If your contract doesn’t spell out exactly the limits of your responsibilities, you could get blamed for problems you didn’t cause, decisions you didn’t make, or failures from third-party vendors you can’t control. So, before you offer project-based or strategic technology services, let me offer you six contract issues every MSP, IT consultant, and fractional CTO must address.

1) Define your role

As a strategic advisor, you provide guidance, recommendations, planning, technical insight, and implementation support. When serving in an advisory role, it’s natural for your customers to start to view your company as a pseudo-company officer or a company fiduciary—but don’t let them do that.

You don’t want your business relationship to be that of an officer, director, fiduciary, full-time employee, or internal technology department. Those positions and titles come with lots of actual and potential responsibilities, none of which are likely covered (or even contemplated) by your agreement or scope of work.  

Remember: If you let the project scope lines get blurry, so will your responsibility. If the customer later says, “You were our CTO,” or “You were in charge of our technology,” you may be blamed for decisions the customer made, risks the customer accepted, systems the customer failed to maintain, or recommendations the customer chose not to follow.

To avoid this situation, explicitly frame your role as an independent contractor and strategic advisor. Your agreement must make it clear that the customer retains final decision-making authority over all business, legal, financial, operational, security, staffing, compliance, and technology decisions.

2) Control the scope before the scope controls you

The scope of project work and consulting engagements can spiral quickly. What starts as “help us figure this out” can easily become “manage the project, fix the vendor issues, train the team, rewrite our processes, improve our workflows, select the software, oversee implementation, and stay involved until everyone is happy.” That may be fine if that is what you agreed to, and you’re charging appropriate rates for that type of work, but it should not happen by accident.

Your scope of work must say what is included, what is excluded, and how changes will be handled. There should be no vague promise to keep working until the customer is “ready,” “optimized,” “secure,” “efficient,” or any other expensive word that sounds good in a sales conversation but becomes dangerous in a dispute. A good project or consulting scope should include specific deliverables, approval points, customer responsibilities, assumptions, exclusions, and a clear definition of “complete.”

Here’s a simple test to determine if you’re clearly and properly defining the scope of your services. Before you send your next project or consulting quote to a customer, ask yourself, “Does this clearly describe what I’m going to do, what I’m not going to do, what I expect of the customer, and when I can declare the project to be completed?”

If you can’t answer those questions in your quote, then your customer may answer them for you later. And rest assured, if your customer is supplying the answers, they will be far less favorable, and far more expensive, to you.

3) Put a fence around AI

AI creates enormous opportunities for MSPs, consultants, and fractional CTOs. It can help with ticket summaries, log analysis, workflow automation, documentation, customer support, security recommendations, and internal efficiency. It can also create enormous risk.

AI produces inaccurate results. It hallucinates. It generates biased or incomplete output. It misunderstands context. It can make recommendations that look authoritative but are flat-out wrong. In some cases, AI tools may even automate actions without sufficient or necessary human review.

If you are using AI in connection with your services, do not simply say, “We may use AI.” That is not enough anymore. Your agreement or scope document should explain how AI may be used, where it may be used, what it will and will not do, and who is responsible for reviewing and approving the results.

Are you using AI to draft documents? Summarize tickets? Analyze logs? Build workflow automations? Recommend security settings? Review configurations? Those are very different use cases, with very different risk profiles.

AI needs governance, and that’s where your agreement comes into play. Your contract should make clear that AI is a tool, not a substitute for customer review, business judgment, legal compliance, management approval, or common sense.

The same is true if your customer will be using AI. Your customer should be responsible for deciding what data may be uploaded, who is allowed to use the AI tools to which it has been granted access, which use cases are approved, and whether AI output is accurate before anyone relies on it.

Don’t become the accidental guarantor of every prompt, output, automation, and bad decision made by AI.  Set up proper parameters and governance guidelines, and allocate the responsibility and risk for AI use where it belongs—with your customer.

4) Be careful with compliance language

Compliance is one of the easiest areas for an MSP to unintentionally overpromise. There’s a big difference between helping a customer prepare for compliance and guaranteeing that the customer is compliant.

For example, a gap analysis or remediation engagement may involve reviewing your customer’s IT environment, identifying deficiencies, recommending changes, and helping implement technical controls. But that is very different than declaring that your customer is fully compliant with a particular law, regulation, or framework. You may be delivering the former, but your customer may be expecting the latter.

That distinction must be clear.

Compliance often involves more than technology. It may involve written policies, employee training, physical safeguards, HR practices, legal analysis, vendor management, risk assessments, documentation, and ongoing operational discipline. An MSP may play an important role in supporting those efforts, but that does not mean the MSP is qualified, or willing, to certify full compliance across its customer’s entire organization.

Your agreement must explain the specific compliance-related services you are providing. Are you performing an IT gap analysis? Are you helping remediate technical deficiencies? Are you assisting with documentation? Are you preparing the customer for an audit or assessment? Are you implementing controls? Say it clearly.

Just as importantly, say what you are not doing. Unless you truly intend to do so, do not allow your agreement, proposal, or marketing materials to suggest that you are guaranteeing compliance, certifying compliance, or assuming responsibility for the customer’s regulatory obligations. If you’re not clear, your customer may later argue that your “compliance service” meant something much broader than you intended.

5) Protect your intellectual property and know-how

When you perform strategic technology work, you bring experience, templates, processes, methodologies, tools, documentation, workflows, automations, scripts, configurations, and know-how to the table. You may also develop new ideas or improvements during the engagement. That’s all very valuable stuff, so you need to be very careful about what the customer owns and what you retain.

Think about a home builder. The builder constructs a house for a customer, and the customer owns the house. But the customer doesn’t own the builder’s tools, techniques, experience, vendor relationships, project methods, design ideas, and every lesson the builder learned while completing the job. If that happened, the builder might have a very hard time building the next house.

The same principle applies to MSPs, consultants, and fractional CTOs. Your customer may own the specific final deliverables that were created for them, assuming your agreement says so. But you must retain your pre-existing intellectual property, general knowledge, reusable tools, templates, scripts, processes, methodologies, ideas, and know-how. This matters because, just like the home builder, you’ll need those things for your next customer.

It’s a crucially important issue, because the wrong IP-related provisions could significantly restrict your ability to serve future customers. Don’t give away the proverbial farm. Make sure your agreement clearly distinguishes between customer-owned deliverables and your retained materials and intellectual property.

6) Do not own what you do not control

MSPs and fractional CTOs are often asked to recommend vendors, platforms, applications, cloud providers, cybersecurity tools, backup solutions, AI platforms, and other third-party services. That is a valuable service. But recommending a vendor should not mean guaranteeing the vendor.

Your agreement must make it clear that if upstream vendors fail, change their terms, suffer outages, discontinue features, introduce bugs, or fail to perform, you are not liable for their acts or omissions.

On the flip side, you may be responsible for exercising reasonable care in evaluating, recommending, configuring, or implementing third-party solutions within the scope of your work. But that is very different from being responsible for a third party’s performance or lack thereof.

So, what should you do when your customer insists that you take responsibility for the acts and omissions of vendors that you brought to the table? How do you counter your customer’s argument that you, and not they, are in the best position to evaluate vendors and, as such, you should be responsible for their good, bad, and ugly activities?

If your customer insists you take responsibility for a vendor’s failure, try to explain to them that you cannot be held responsible for a third-party’s actions, any more than they should be liable for a package mishandled by a shipping service and consequently never delivered. If they continue to insist, either walk away from that deal or price it accordingly—and make sure you have enough insurance to cover the parade of potentially horrible things that could occur.

The bigger point

Project work, consulting, and fractional CTO services allow you to move up the value chain, become more strategic, and help customers make better technology decisions. But the legal structure has to match the service.

The danger is not always in what your agreement says; sometimes the greater danger is in what it fails to say. Silence creates room for assumptions. Assumptions create disputes and disputes create liability.

Before you offer project work, strategic consulting, AI guidance, compliance assistance, or fractional CTO services, make sure your agreement answers the issues discussed above. If it doesn’t address those issues clearly, then the customer, a court, an auditor, or a plaintiff’s lawyer may address them for you.

For more legal advice, learn why QBRs are not optional—unless you want to be liable.