Based on the explosive growth of smartphones over the last three years, Bring Your Own Device (BYOD) policies have been widely adopted for corporate email and other work-related tasks. Industry analysts, however, are starting to indicate that BYOD is failing to deliver on many of its promises, that its implementation is riddled with potential pitfalls, and that many companies fail to implement standard security policies essential to using BYOD.

As we have previously discussed, cybersecurity threats are mounting and are a major concern for senior management. In this month’s first Contract Corner post, we discuss contract provisions that cover the implementation and maintenance of proactive and preventive security measures. Below we list some key issues to consider when drafting these types of security provisions.

Documenting Security Requirements

As part of the contracting process, the vendor should agree to abide by the terms of a detailed security plan that meets or exceeds a customer’s requirements. When developing this documentation, consider how the vendor will do the following:

  • Ensure the security of customer data—Will the vendor warrant a specific, detailed security system, or will the customer rely on conformance to more general security standards? How will the vendor monitor security risks and breaches?
  • Protect against viruses and other threats to the integrity of customer data—Will the vendor warrant the absence of viruses or merely a standard of prevention? Is the vendor obligated to remediate all viruses, even if it did not cause them?
  • Protect against unauthorized access of customer data—What technology and processes will the vendor use to control access? What are the customers’ responsibilities, and how will the vendor test its defenses and notify customers of any unauthorized access?
  • Improve security systems—Will the vendor agree to meet or exceed best industry security practices as they evolve in the future?
  • Change any security measures—Will any vendor-initiated security changes require the customer’s consent? Will the customer have the ability to require changes?

EisnerAmper's Fifth Annual Board of Directors Survey highlights cybersecurity breaches and social media use as top risks that concern boards of directors in 2014. With reputation, cybersecurity, and social media largely intertwined, the survey notes that the associated risks have captured the attention of most boards.

The survey’s key findings include the following:

  • Cybersecurity climbed to the second most important area of risk management to boards, only behind reputational risk. Yet, boards displayed confidence levels below 60% for both their CEOs and CFOs when asked if such individuals have a strong understanding of cybersecurity.
  • Boards also showed little confidence in their management’s knowledge of social media. In fact, many executives admitted that they lacked understanding of new media and cyber issues, which are areas where “mere general knowledge can miss the critical nuances necessary for effective strategic and operational decisions.”

The survey interestingly shows that, as data breaches become more public (affecting reputations and brands) and regulation with respect to reporting breaches gains more focus, cybersecurity and social media risks are not only operational concerns, but also gain attention at the highest levels.

The U.S. Copyright Office recently released a third-edition public draft of the Compendium of its practices for comment. The final version is targeted for release in December and will serve as a guide to fundamental principles of copyright law and a technical manual regarding copyright registration, documentation of copyright ownership, and recordation of copyright documents, including assignments and licenses. With the last edition published more than 20 years ago, we have summarized below some notable new aspects, particularly with respect to changes driven by the Internet and new technologies.

The hospitality industry is particularly focused on data analytics and is the recipient of a large volume of end user data. To follow up on the privacy policy topic we discussed in the previous post in this series, we reviewed a hotel’s privacy policy to highlight several concepts that work together to establish broad use and disclosure rights. These concepts include the following:

Building on our introductory discussion of data analytics and use restrictions from last week, in this post, we describe in more detail some potential restrictions, under applicable law and contracts, of a company’s ability to use data for analysis purposes.

  • Third-Party Terms. If a company plans to use data owned or sublicensed by a third party, or jointly owned by the company and a third party, for analysis purposes, the applicable license, services, or other agreement should be reviewed because it may control the company’s use rights with respect to the data. The company should confirm that it has the necessary rights to use the data and, if applicable, whether the third party that owns or licenses the data has the right to grant such a license. If the company’s right to use the data is unclear in any way, it should obtain consents to such use from the owning or controlling party or parties. Companies should also consider seeking from the third party that owns or licenses the data an indemnity against third-party claims that arise from any failure to have such necessary rights to use the data.

We hope our readers can join an October 9 webinar presented by Labor and Employment partner Barbara Miller and associate Kathryn McGuigan on the legal risk and potential privacy issues for California employers arising from bring your own device (BYOD) policies. The webinar will also address recommended steps for employers to ensure compliance in BYOD policies and practices.

This webinar will be held Thursday, October 9, from 1:00 to 2:00 pm ET. Sign up here >

Companies’ use of data analytics is booming, with businesses seeking to leverage large amounts of raw data to analyze trends, make decisions, and enhance products, services, and marketing opportunities. However, when analyzing this raw data, companies should be mindful of the data’s source(s) and the use restrictions that may apply under applicable law and contracts.

Picking up where we left off last week, below are some additional key issues to consider and address when negotiating source code escrow provisions.

  1. Duration of Source Code Use. The license grant following the source code escrow release event should specify the duration of the customer’s source code use rights. Typically, the source code license rights will have the same duration as the customer’s original license rights under the license agreement, as they may be renewed by the customer. This approach is consistent with section 365(n) of the U.S. Bankruptcy Code. Two typical source code use durations are as follows:
    1. If the original license is a term license and the customer elected to retain the license under section 365(n), the source code license would have the same term. The customer would have the right to renew the source code license using the same methodology as would be applied to renewals of the original license rights in the license agreement.
    2. If the original license is perpetual, the source code license would also be perpetual.

Source code escrow arrangements can be a contentious topic in software license negotiations. Vendors are reluctant to make their proprietary source code available to third parties, while customers are concerned about business disruption if the vendor goes out of business or otherwise stops supporting the software. Below, we have outlined some key issues to consider and address when negotiating for the source code escrow remedy. We will continue this list in a post next week.

Is release an effective remedy?
Given the amount of time that often goes into negotiating for source code escrow provisions with vendors, before requesting this remedy, customers should consider whether they would want to, or would be able to, effectively use the source code once they receive it. Customers may choose not to negotiate for source code escrow if (a) they do not have, or do not want to engage, in-house expertise and other resources necessary to host and maintain the code themselves and/or (b) there are other solutions available in the marketplace that the customer could transition to if needed.