Q. So, Cary, what exactly is “cyber liability insurance”?

A. Cyber liability insurance is insurance that allows a vendor to outsource the risks that remain after it has implemented direct, technical computer security measures and attempted to limit its contractual liability to customers.  Since typical commercial general liability (CGL) and errors and omissions (E&O) policies rarely cover “intangible” losses related to loss of data, privacy breaches, and the like, cyber liability insurance policies are intended to fill that hole to address the particular needs of a company doing business in the cloud.

Q. Why should SaaS/cloud providers strongly consider cyber liability insurance?

A. Unlike traditional enterprise software vendors who ship software to their customers to run locally, SaaS and cloud-based service providers receive and maintain business and personal data on behalf of their customers.  The value of this data to the customer often exceeds the cost of the service.  So, customers are not shy in asking for security and confidentiality liability that far exceeds the profit the provider can expect.

Providers rely on a myriad of employees and third party vendors (cloud platform providers, collocation facilities, system integrators, solutions providers, etc.).  However, these folks cannot or will not provide adequate liability coverage for the security breaches they may allow.  After security policies and procedures have been put in place and agreed to, cyber liability insurance increases the providers’ ability to offer liability levels that go beyond the value of the contract.

Q. There is a lot of media hype around security issues but just how big is the risk of a real data breach?

A. Data breaches can come from any number of causes: unauthorized access to online systems, denial-of-service attacks, and introduction of viruses and malicious code, any of which may result in loss, dissemination or destruction of electronic data, business interruptions, privacy law violations, disclosure of non-public personal and or confidential information, and, potentially cause financial harm to the persons whose data is released, as well as the provider.

Fixes can be expensive: detection, escalation, notification and response along with legal, investigative and administrative expenses, customer defections, opportunity loss, reputation management, and costs associated with customer support such as information hotlines and credit monitoring subscriptions.

Recent studies provide varying results regarding the cost of data breaches, but they are always expensive:

• A recent survey by the Computer Security Institute found that the average company financial losses due to security incidents exceed $230,000.  The Ponemon Institute puts the average total per-incident cost even higher at $6.75 million, with an average cost per compromised record of over $200.
• In the CSI survey, wireless related exploits were the most expensive, averaging $770,000 in losses per incident, followed by theft of personally identifiable information or personal health information through all causes other than mobile device theft ($710,000), and financial fraud ($450,000).

Rogue employees are part of the problem, resulting in data security issues 43% of the time.  But accidents can happen too:  25% percent of survey respondents felt that over 60% of their financial losses were due to non-malicious accidents by insiders.

Q. If I’m a cloud provider, can’t I just pass some of the liability on to my vendors?

A. You could pass some of the liability for your vendors back to them, if they were willing to accept it.  Problem is, they are not.  I have negotiated enough contracts with cloud platform providers, collocation facilities, telecommunication providers, solution providers and others to know that they will simply not take on the liability for damage to your business or your customers’ businesses resulting from their data security breaches.  (I’ve actually heard counsel for a colo extol the virtues of its security procedures, only to assert that it should have zero liability for data breaches because placing a box in the facility does not constitute disclosure of the data. At least they offered to cover the cost of the lost hardware if one of their employees walked off with it.)

Inevitably, you will be stuck in the middle between your customers and the third party vendors you use to provision your service at a reasonable cost.  Remember that agreements with vendors should require that they carry a cyber/privacy liability policy that names you as a third party beneficiary.

Q. How do I decide what cyber liability insurance I need?

A. To decide what kind of cyber liability insurance you need, first evaluate your existing policies, and ask yourself the following questions:  Am I covered for loss of electronic data?  Is electronic data stored on media covered?  Are first party claims covered (damage to your company’s electronic data or equipment)?  Are third party claims related to electronic data loss covered (in other words, customers who claim you damaged or lost their electronic data, or personal information)?  Newer commercial general liability (“CGL”) policies typically exclude electronic data loss from coverage as electronic data is excluded from the definition of covered tangible personal property.

You should also consider whether any of the following types of damages and claims are covered or expressly excluded from your policies: DNS and other types of hacker attacks (causing downtime, and potential exposure to your customers); transmission of malicious code; data released by rogue employees or by employees making innocent mistakes; security breaches; business interruptions; privacy violations, including disclosure of personal information or customer personal information, and incidents related to unauthorized access to company online systems; unauthorized access to credit card information; notification and other expenses incurred in remedying a privacy breach; expenses related to customers’ claims; costs to investigate and restore data.  In reviewing these scenarios in your existing policies, examine how and whether intentional acts are excluded from coverage; and whether fines, penalties and related settlement costs are covered in any policy.

Also consider whether your current policies cover liability assumed under contract.  A CGL policy may not cover liability assumed under contract; they primarily cover tort liability.  It is good practice to consider obtaining coverage that expressly covers contractual undertakings, for example, indemnity for privacy breach, as this will give you some flexibility in the types of promises you can safely make to customers.  In addition, look at whether your policies cover acts of subcontractors (such as data that is lost/damaged by your collocation provider facility or by your consultants).

Finally, think about the kind of data you are storing online and where is it being stored.  Does it contain any personally identifiable information (“PII”)?  If yes, then at minimum, you’ll need privacy liability coverage.  Is the data encrypted?  What techniques are you using to protect unencrypted data?   This is quite important since some insurers may include policy exclusions for unencrypted data.  Are you transmitting, or do you plan to transmit any PII from Europe to the US?  If so, are you US–EU Safe Harbor certified?  Do you have good procedures in place for a data breach event? Do you have a disaster recovery and business continuity plan in place?  These things matter in terms of whether you can get a policy, and how much it will cost.

You might consider “cyber extortion” coverage if you are concerned about the risk of having to pay a ransom amount demanded by a hacker threatening to shut down your company’s network/services or steal private information.  These policies often include forensic or investigative costs to help determine the validity of the hacker threat, and there is usually no deductible because the carrier views this as a proactive measure that could prevent larger damage and loss.

This isn’t an exhaustive list – consider other loss scenarios not mentioned here to determine with your broker what other risks should be covered.  For instance, Mike Gilmore of Crump Insurance Services, Inc. in San Francisco highlights that intellectual property infringement and personal injury claims arising our of technology products, services and website activity are often covered with a cyber liability policy.  Software copyright infringement claims are fairly common for software code.  And he’s seeing more and more personal injury claims arising from company websites that contain blogs where individuals can post comments, pictures, and otherwise, that can be defamatory, slanderous, and damaging to reputation.

Another good source of information is the IRMI.com website which includes some ideas to consider in evaluating various loss scenarios.

Q. What other steps can I take to limit my liability with cyber liability insurance?

A. Many carriers are offering proactive services in addition to the risk transfer in the cyber liability policy, including forensic experts and consultants who can help mitigate a security/privacy breach, legal experts to advise on requirements per state, public relations support, and even 24-hour IT support for guidance if a company thinks it may have a privacy breach situation or hacker threat.

One interesting area of coverage to discuss with your broker is regulatory defense and indemnity coverage to cover fines and penalties where insurable by law, for example the costs associated with a settlement with the FTC in the event you violate your own privacy policy.  Think about your posted Privacy Policy, and whether your internal procedures comply with your public promises.  If not, and your system is hacked, you may have exposure to FTC action, potentially leading to costly fines, penalties, and remedial actions.

Using its authority under Section 5 of the FTC Act, which prohibits unfair and deceptive practices, the FTC has brought a number of cases to enforce privacy policies, including promises about the security of consumers’ personal information.

A good recent example of this was the settlement by Twitter with the FTC for Twitter’s lax security practices. The case involve two hacking incidents in 2009, one in which a number of high profile accounts were compromised, and another in which a hacker gained access to a Twitter employee email account containing the employee’s administrative password.  Under the terms of the settlement, Twitter was barred for 20 years from misleading consumers about the extent to which it maintains and protects the security, privacy, and confidentiality of nonpublic consumer information. The settlement also required Twitter to establish and maintain a comprehensive information security program, which will be assessed by a third party every other year for 10 years.  Similar settlements between the FTC and various technology companies over security breaches can be found on the FTC website.

First be sure there is a broad definition of “Claim” so coverage applies to demands, investigations, requests, complaints, and civil, criminal, and administrative and regulatory proceedings.   In terms of FTC and other government agency activity in the privacy arena, this is becoming increasingly important.

Evaluate the definition of “Loss” to ensure coverage encompasses a wide scope of relief, including statutory, and regulatory fines and penalties, defense, investigative and settlement costs.  Clarify that disruption, corruption, deletion, theft, or copying of data, software, or programs whether stored electronically or on good old fashioned paper is deemed to be “physical loss or damage” to potentially avoid coverage issues for loss or damage of electronic data.  Seek to add a provision covering the cost of making a determination that reconstruction of data is impossible.  Look for coverage for unauthorized use by authorized users.  Check for coverage for loss of use by a third party.

Examine the “Exclusions” to coverage to ensure they are narrow and contain “exceptions” where coverage will be provided.  If possible determine if exclusions for bad conduct by officers, directors or company employees will be triggered only by a final adjudication of the excluded conduct.  Defense costs should be covered, and the exclusions should be severable, so that one rogue employee does not disrupt coverage for all.  Make sure the cost to replace or restore electronic data is not excluded.  And review the “insured versus insured” exclusion to ensure you have coverage for your own employees as long as you are buying the coverage.

Finally examine the duty to mitigate damages carefully.  “Covered damages” definitions often exclude the cost of repair if you did not take prompt, reasonable measures to address a security breach.   In part this why you should take a pre-coverage security assessment, continually improve security procedures, and conduct internal training on them.

Q. OK, I’m convinced!  But how do I sell this internally?

A. Ted Doolittle of Risk Placement Services tells me tech providers often think they are immune to the risks identified here.  From a tech perspective, they’ll say they don’t have exposure because their systems are airtight, or that they don’t have time for the steps involved in obtaining insurance, such as third party security audits, lengthy applications, etc.  From a finance perspective, they’ll simply say that cyber liability insurance is not in the budget.  Hopefully, the information in this article will give you some ideas about how to discuss the issues and justify the purchase.  Given the risk of litigation associated with dealing with personally identifiable information (PII), he recommends that tech providers get at least a policy to cover the defense costs associated with a claim.  The process for obtaining coverage, he says, is much more streamlined that it was even 1 or 2 years ago.

Q. If people want to contact you directly to discuss this issue in more detail, what’s the best way?

A. Just have them email me directly at cary@platkinlaw.com

« Hide It

Bruce:  What key terms should a SaaS Agreement contain?

Cary: SaaS agreements are typically subscription services agreements that address key customer concerns with service levels, security, privacy, and ultimately performance.   

More detailed SaaS-specific issues include: how mid-term add-on user subscriptions are handled; the details of the renewal process; whether support is bundled in or extra; what usage rules apply to your users; and how third party services are made available through your service.

There are many ways to address these issues depending on your particular business, but one thing is clear – SaaS providers need to ensure their hosting and other services vendors are providing “back-to-back” terms for the terms being offered to customers. 

If you use outside vendors to provision your service, it is critical that you secure the same or better terms from your hosting vendors than your customers will seek from you.   If your vendor doesn’t back you up on the commitments you’ll need to make, you’re really out on a limb.  On one hand, you might choose to manage your risk tightly by seeking a one-off exception from the hosting vendor, but this can slow the sales cycle.  On the other hand, you might choose to accept the risk, close your sale quickly, and make contract commitments that your hosting vendor cannot or will not back up.

Sometimes the risk is merely a matter of numbers that you can easily analyze.  For example, say your SLA is 99.9% with one day of credit for each one hour of downtime.  Your vendor has agreed to provide you the same basic SLA and credit, so you feel comfortable with that arrangement.  But what if a good handful of customers demand 99.99% and two days of credit for each one hour of downtime?  Your risk is merely the delta between the coverage you have from your vendor and the commitment your customers want you to make. 

Crunch the numbers and cross your fingers.

Sometimes the risk is more cut and dry.  For example, say your customer insists it must be permitted physical access to the hosting facilities and full access to the detailed SAS 70 Type II security audit reports on the hosting facilities.  If your hosting vendor limits physical access to its facilities and restricts your right to distribute the revealing audit reports (both common security measures), then promising these things to your customer is simply not possible without an exception from the hosting vendor.

So as you develop your contract terms early on, anticipate your customers’ demands, think through the details, and insist that your vendors get on board with your business and your customers’ needs.

Bruce: Speaking of SLAs, should a SaaS company offer a Service Level Agreement, and if so, what are the key terms they should spell out in the SLA?

Cary: Whether to provide an SLA or not is a business decision based on customer demands and competitive landscape.  Obviously, if you can avoid making a commitment, most lawyers will tell you that’s a good thing.

However,  I think SLAs are a critical element to successfully market a SaaS offering, and more and more, SLAs are required to adequately compete with both on-demand and on-premise alternatives.  If your SLA is world-class and you can make your current performance metrics constantly available to customers, your customers will appreciate it, even if your system goes down from time to time.

There are many types of SLAs, so the first question is what are you going to measure and commit to?  Support levels (response times for support tickets) and system availability are minimum requirements for today’s SaaS offerings.  You might also offer SLAs around reliability — number of outages or time between outages — or response time for your system’s ability to turn around input and output.  Beyond that, I think it can be a bit difficult to offer accessibility, performance or scalability SLAs because there are so many factors that contribute to these issues. 

In any event, most customers want the availability SLA and the performance warranty to run in parallel, so if the system is down for an extended period of time, the customer can max out its SLA credits, and still terminate the contract for breach of warranty if you are ultimately unable to fix the system.

When drafting your SLA, describe in great detail:

• the definition of metric being measured (availability, reliability, etc.); 
• how the SLA percentage is calculated;
• the permitted exclusions to performance, including scheduled maintenance, customer-caused problems, and other issues outside of your control; and
• how credits (or refunds) are calculated and applied to customer accounts.

One tip about credits:  don’t over-do it.  The biggest and best SaaS providers experience downtime events on a regular basis.  No one expects dial-tone availability, and you probably only marginally better than the customers’ own internal IT staff.  You don’t want one or two events to wipe out your business.  One day of credit for each hour of downtime is typical, but only after the system has already fallen below your target availability level and only for use with renewal terms.

Bruce: What terms do you feel should never be in SaaS Agreements?

Cary: I have been encouraging my clients to hold the line on accepting unlimited liability for confidentiality breaches. 

While security of the system and privacy of the customer data are critical customer concerns, you are not Fort Knox.  You can and should use the same type of security measures that other vendors in the industry use.  But if a hacker gets in despite these measures, is it really fair to hold you fully responsible for the damages?  If you said “yes,” then you agree that your monthly subscription fee is adequate to cover not only software and hosting services, but unlimited insurance against this common business risk.  Assuming you were able to buy insurance for this risk, how much do you think unlimited coverage would cost you?   Some multiplier of fees paid, up to a comfortable cap in the high 6 or low 7 figures, is probably adequate to close most transactions – why accept more and put your entire business at risk for something no one can absolutely guarantee?

You might be surprised to learn that other terms that might not be necessary in your SaaS subscription agreement are traditional software license terms.  If your offering is a pure multi-tenant hosted offering without any local client for the customer to use, then you are merely providing access and use of a service.  You are not licensing software in the manner most customers are accustomed to.  This is a subtle but important distinction for your template subscription agreement – SaaS is easier to sell when you continually reinforce the notion that this is not a software license plus associated hosting and managed services.  Rather, it’s a subscription service that is offered the same way to every subscriber.  There’s no delivery of software, no need for source code escrow, and most importantly for the multi-tenant solution, no custom hosting services terms often found in ASP or managed services agreements.  

Bruce: How should a SaaS company set up its Agreements from the beginning so it can avoid revenue recognition problems downstream?

Cary: I am not an accountant so I can only speak to the kinds of terms clients have told me are important to them.  First, SaaS providers know that revenue recognition is one of the great barriers-to-entry for publicly-traded enterprise software companies.  This is because subscription services revenue is recognized ratably over the life of the agreement as the services are performed, which runs contrary to the up-front revenue recognition model of traditional  software license deals.

Pure play SaaS providers build stable annual revenue streams that end up being more predictable.  So, the key to success with subscription agreements is to do all you can to keep the revenue flowing and renewing.    

Although revenue is recognized differently, accountants tend to care about the same issues that arise with standard software and services:  

• Acceptance terms should be avoided (the free 30-day trial and smaller up-front start-up costs have made this easier for customers to bear);
• Payment terms should not be extended too far into the future;
• SLAs should be achievable and warranties should be “documentation” based; 
• remedies for breach of these commitments should be credits on future services only, no refunds of fees paid;
• termination for any reason should result in refund of unused prepaid fees only, not fees for services rendered prior to the date of termination.
• future product commitments should be avoided. 

Bruce: What about multi-year Agreements? Should companies execute multi-year Agreements? If so, for how long?

Cary: Multi-year agreements are great for business — I haven’t met a person selling SaaS yet who preferred short-term subscriptions.  Multi-year contracts are typically procured through the use of higher discounts on fee that are paid annually in advance (or for unconvinced customers, quarterly in advance for the first year and annually thereafter). 

Customers being customers, they love discounts, but hate commitments.  So, I usually recommend terms that require the customer to pay the delta between the discounted multi-year rate and the higher short-term rate in the event it terminates the subscription mid-term or at the end of the shorter term.  SaaS providers with better leverage might even suggest some percentage of terminated subscription fees (up to 20%) as an early termination fee.

Bruce: If a SaaS company is planning to handle customers/data from the U.K./Europe/Asia, will they need make any special provisions?

Cary: This is a very complicated question that depends on many factors including where your company is incorporated, where your data centers and support staff are, where your customer is, where their end users are, what kind of customers they are, what kind of data they are uploading to your system, etc.

The easy answer is if you are a US company that has been selling to US customers, and you are suddenly selling into international markets, you should probably seek knowledgeable US or local counsel to work with your finance team to iron out required terms.

The most common issue that US SaaS providers face early on is Safe Harbor certification.  Many EU customers will not do business with a US company holding personally identifiable information unless it warrants that it complies with the UE-EU Safe Harbor framework.  Participation in this program requires annual self-certification that your company complies with security and privacy standards set forth by the US Department of Commerce at www.export.gov/safeharbor.  I do caution clients not to over-commit to the customer here – EU customers have their own requirements to comply with privacy regulations.  When you are holding and processing data on behalf of your EU customer, you can only really commit to security terms, but issues related to the direct relationship between your customer and its individual end customers can only be managed by your customer.  A simple example:  if privacy regulations provide that the individual should have the ability to “opt out” of marketing programs that use their personal information, only your customer can manage this obligation, so it is not likely that you are in a position to help or hurt their compliance with this regulation.

Bruce: Are there simple things  a SaaS company can do develop a easy, scalable contracting process?

Cary: Perfecting the contracting process is often overlooked, but it can have such an important impact on close rates, cash flow, and customer satisfaction.  From a legal perspective, the easiest thing you can do to close contracts quickly is to use fair, industry standard terms that meet or exceed your customers’ expectations.  For each term in your subscription agreement, you should know not only the industry standard and your customers’ expectations, but also how much risk you are willing to tolerate.  Your law firm’s standard software or services agreement probably won’t do here.  You really need to think through each of the issues, or you’ll learn the hard way as customers begin to question certain provisions with each new deal.

 From an operational perspective, you’ll want to use an automated contract management system that integrates with all of your company’s workflows.  As such, you should solicit input from all of the company functions that touch this important process:  sales, sales operations, finance, legal, provisioning, and support.

If the offering is marketed to the low-end of the SMB market, then an online transaction system with a posted click-to-accept subscription agreement is ideal for an easy, scalable solution.  However, this is rarely sufficient for my clients – even if they can use an ecommerce system, there are always clients who want to negotiate terms or even use their own agreements.  So there has to be an exception process, and an 80-20 goal (or better) of closing as many deals as possible without business or legal exceptions.

I find that the best contracting structure for most SaaS companies is a simple page or two order form generated out of a sales order processing system.  The order form should contain all the applicable customer information, products and pricing being purchased, and a space for one-off terms applicable to the deal (future discount provisions, early termination rights, etc.).  And most importantly from a legal perspective, it should state that acceptance of the order form (by signing the form, emailing acceptance, or issuing a PO) constitutes acceptance of your posted subscription agreement (including the URL).  The posted subscription agreement can in turn reference other posted policies such as support policy, SLA, security policy, etc.  You should have a Word version of the subscription agreement and the related policies available for prospects that request the ability to redline.

Finally, your lawyer can help you minimize legal fees for negotiations by helping you prepare tools that empower non-lawyers to close deals with standard exceptions.  These tools may include:

• a list of regularly-used alternative business and legal terms,
• a “playbook” that describes the purpose of the various clauses in your contracts and provides alternatives,
• an approval matrix to ensure that the right people around the company are approving exceptions to standard terms.

* * *

Legal Disclaimer.  The materials available at this web site are for informational purposes only and not for the purpose of providing legal advice. You should contact your attorney to obtain advice with respect to any particular issue or problem. Use of and access to this Web site or any of the e-mail links contained within the site do not create an attorney-client relationship between Platkin Law Offices and the user or browser.

« Hide It