<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=179060&amp;fmt=gif">

Minerva Labs Blog

News & Reports

MSPs: Defining Your Security Services Commitments

If you’re thinking of adding on a security services offering to your practice or already have such a solution, confirm that your customers know what to expect from your security service.

Unlike managed services where the scope of work responding to an issue is somewhat known (e.g. a workstation dies, and you have a known process to reimage and/or replace the endpoint), with security, there are a lot of unknowns. Questions like “How many endpoints have been breached?”, “Which ones?”, “Was data stolen?”, or “What’s being held for ransom?” will have differing answers with each attack.

Because these tangible unknowns exist when adding a security service offering, it’s important to communicate to your customers what they can expect from you. You could accomplish this using a formal Service Level Agreement (SLA), though given the open-ended nature of security services, MSPs often avoid formal SLA contracts and instead create guides that set expectations in terms of services performed and response times, while recognizing that no security controls could prevent all incidents.

Register for the webinar! 

When documenting the details of your security services, be sure to capture the following SLA-related items: 

  • Set Service Expectations – Ensure you and your customer are agreeing on the nature of the services you’ll be providing. This helps protect you as much as it does your customers by defining exactly what’s included (and NOT included) in the offering. In addition, your documentation should include target response times, possibly outlining that resolution times are either specifically not defined or are simply best effort.
  • Protect Your Business – Because there is so much that can go wrong that is out of your control, your documentation should establish that while you are providing the service, you cannot guarantee 100% protection.
  • Define Customer Obligations – Take the time to establish some of your expectations of your customer. For example, you might require customers to configure their endpoints so that users are not allowed to install unsanctioned software, browser plugins, etc. that may be a vehicle for a security breach.
  • Pave the Way to Settling Disputes – While you can’t completely eliminate disputes (especially if things go wrong, such as your customer becoming the victim of a malware infection), your documentation should help clarify whether you met your obligations.

In addition to setting expectations and clarifying commitments, what else should your security service documentation contain to help you deliver a valuable offering?

 

  • Scope – It’s important to spell out exactly what security services are included: for example, are you simply providing layered protection using software solutions, or does this come with incident response included? Define what systems are included, the security service, and what’s not included (to be certain the customer understands the scope). It’s also important to not put your practice at risk by overcommitting. For example, your service might include patching, but committing to being 100% when there are external factors that may impact your ability to do so may be business suicide. Be sure your scope definitions include clarifications such as “We aim to patch systems in 30 days or less, but recognize that sometimes factors outside our control can make this impractical.”
  • Support – When and how you will provide support should be stated. Be specific here: using phrases like “8x5” may get you into trouble. Clearly state the days of the week, hours of the day, and methods (on-premises, remote, etc.). Given that one or more security software solutions should be a part of the defined service, be sure to include keeping and maintaining the solution(s) running as part of support. Additionally, if there are added charges to be incurred outside the stated support hours or scope of service, put that into the documentation as well.
  • Reporting a Problem – Customers need to know how they should communicate an issue to you. List the basic steps, so customers are aware they must submit a ticket and not, say, text you directly. Different issues may also require different reporting mechanisms – the detected presence of ransomware requires much more immediate attention than an error popping-up from the AV software about not receiving an update. If you have tiers of issues, establish the appropriate reporting mechanisms for each.
  • Response – Inform the customer how long you will take to respond to a reported incident, possibly in terms of a likely timeframe. Clarify what “respond” means in this case, for instance by setting expectations regarding the time it will take for your staff to begin investigating the reported issue. Again, if there are tiers of response (aligning to the criticality of the issue), state each response time.
  • Resolution – Non-security IT service SLAs often define how long it should take you to resolve an issue. But in the case of security-related issues – like a full-blown ransomware attack that affects multiple systems – you may need to rely on best effort estimates, without making formal commitments to resolution time.
     

Finding Security Solutions to Match Your Intentions

A lot of what you’re going to promise your security service customers really depends on the solutions you choose – their capabilities, use of automation, and what is specifically being protected all impact the very definition of your security service.  And, because you’re placing a lot of faith in your solutions to do a lot of the protection work, it’s even more critical to get this right – one infection, and you may have a ton of remediation work to do that you’re not billing any additional revenue for.

For example, many MSPs rely on endpoint-based AV to do much of the detection of malware, stopping infections from occurring. However, should malware employ evasive techniques, AV may completely miss the attack, thereby allowing an infection and causing more work for you and your team.

The obvious goal with any security service offering is to have the security solutions in place do most of the heavy lifting, providing enough appropriate security to limit the need for any additional manual labor.

To accomplish this, you need to evaluate the mixture of the intended levels of security, service availability, incident response work included, response times, etc. and build a layered security strategy that meets the promised service levels in a way that maximizes your chances of stopping malware attacks, ransomware, viruses, etc. from ever gaining entry into your customer’s networks.

Building a Service that Secures

Good security service documentation defines how you’ll work to protect your customer, while also protecting your business’ ability to thrive.  Your documentation should be detailed, providing specific guidance around what service is going to be provided, how, by whom, when, etc. It’s the central document that is crucial, especially in an attack scenario, where you’re promising your customer to keep them safe while adversaries are bent on doing exactly the opposite.

We mentioned choosing the right solution(s) as part of this article because doing so is going to make or break your company’s ability to keep your customer secure.  Put the right defense in place, and you’ll never have an issue – keeping your customer happy and productive, your profit margins high, and your techs stress-free. By establishing a managed security offering around the right solutions, you’ll be able to deliver on what you promise, while protecting your business in the face of an uncertain foe. 

To learn more, download: Malware and Avoiding the Hidden Cost of Adding Security to your MSP Practice.

  I WANT A FREE TEST DRIVE!