Many MSPs are looking at becoming vCIOs for their customers. The main difference between the vCIO and the Network Admin is that the admin looks at network health, while the vCIO always analyzes the business implications associated with network health. Obviously, a vCIO will focus on areas where the business is impacted the most – even if the network implications are limited. 

One such area is Data Privacy, where an ever evolving landscape of unaligned rules and regulations and standards and certifications all work to assign liability to negligent or sub-standard handling of sensitive data. And the impact to the business from non-compliance can be substantially higher than the risk to the network.

How can the MSP as a vCIO assist their customers in understanding their compliance liabilities? How can the vCIO help customers across different lines of business, different geographies, and different regulation – without becoming compliance officers?

We propose a method that helps the MSP figure out the liability associated with regulatory compliance by measuring how much data is kept by the organization, monitoring how the data is used, presenting it to the customer and devising a target set or risk tolerance. Obviously, should the numbers exceed the tolerance, the MSP should help the customer address the excess liability.     

Enterprises were the first to realize that the complexity of regulatory compliance made it unmanageable, and opted to separate the compliance framework from the control. A mapping between the two allowed a single control to address multiple compliance requirements across multiple regulations and geographies.  Our approach follows in their footsteps – making it even easier by using a risk assessment to start the compliance discussion.

Why is Compliance Important?

Hopefully we can all agree that compliance is important to our customers. As vCIO we have to understand what makes compliance so important to their business, so we can focus on addressing their needs in an efficient manner. There are two main “implications” of being non-compliant:

1.       Uncapped Implications – For a small to medium business – the implications of negligence can be a threat on their survival. This is because – whereas the implications of standard IT risks range from device replacement (a few K$) to lost productivity (10-100K$) – the implications of negligence can lead to aggregated losses (fines + penalties + forensics costs + legal + accounting + insurance) upwards of millions of dollars. 

2.       Inability to conduct business – In some sectors, access to opportunities is dependent on being certified as compliant. 
In these cases, maturity typically helps: For example, banks typically have in house institutionalized knowhow and can guide the MSP into what needs to be done for compliance. Where regulations are new and maturity has yet to happen both the customer and the MSP are left to navigate the waters by themselves. CMMC is such a regulation – without which DoD contractors would no longer be able to compete for tenders.

Compliance is Complex, but Not Difficult

Many MSP start their attempts at understanding compliance by conducting a Google search for compliance or a particular regulation (say – HIPAA) – only to discover a vast subject with little practicality. For example, searching for HIPAA would reveal that while HIPAA is strict with process (like the SRA tool) and enforcement – it lacks any prescriptive certifications and controls. So a cottage industry of HIPAA “certification standards” emerges (like HITRUST CSF) which purport to “meet or exceed” the language of the law and enforcement activity. Confusing (and expensive) at best. 

Exacerbating the problem of data privacy compliance is that there is a smorgasbord of different compliance standards and requirements which makes it difficult to have one solution for different types of businesses. Even if one were to standardize on a particular methodology/certification (like HITRUST CSF) – how would this help regulations like CMMC?

Compliance is a classic “can’t see the forest for all the trees”. Lots and lots of details – but in reality – an MSP can be very effective and help their customers without becoming a compliance expert.

A Practical Approach

Controls surrounding compliance always fall under execution (or process) controls (such as ensuring password complexity) and discovering and monitoring controls or sensors (answering “are we within a defined risk tolerance?”).

Choosing compliant systems (like compliant cloud solutions) helps with the latter without requiring excessive processing. 

Discovering and monitoring controls are key to helping customers understand the implication of compliance. Understanding how the customer uses and stores data puts in perspective the need for other controls. So while every customer needs a firewall. But the risk of not having one, for a customer that stores thousands of medical records – is substantial. 

The practical approach always answers the following questions:

1.       What does the customer do and what type of data do they use?

2.       Conduct a data privacy risk assessment:

a.       Discover how much and where do they keep the data.

b.       Monitor how the data is used.

3.       Analyze the results. If possible, try to correlate the data with different regulations. For example, in a healthcare provider – does the number of ePHI records hit a HIPAA target (like 500 records)? 

4.       Share the results with the customer and figure on a plan to address.  

a.       Define a risk tolerance – how high are they or their insurers willing to go?

b.       Figure out a compensation/risk reduction strategy if their liability exceeds their risk tolerance.

The practical approach uses discovery and monitoring as  a way to build the business knowledge that the vCIO can use to indicate business risks (rather than IT risks).

Additional Opportunities

Obviously there are additional opportunities for the MSP like running system audits and helping the compliance officer gather all the data they will need to pass a certification.  These usually require more expertise and can be learnt on the job. The issue is that to get started – there must be an understanding of the business – and its use of data.

execution (or process) controls (such as password complexity)