In-House Counsel’s Role In Cybersecurity & Data Protection

THE CONDUCTOR CANNOT HOPE TO KNOW EVERYTHING about each section of the orchestra, (e.g., what strings, woodwinds, brass, and percussion must do in order to play their part). However, each section (and subsection) has its own chair who can determine that with the help of internal or external advisors. The role of the conductor is to coordinate and adjust the entire orchestra to create a compliant and harmonious overall data security performance, determining and managing interpretation, balance, tempo, and phrasing.

In reality, this analogy is helpful, but false. In an orchestra, every musician has the composer’s entire score sitting on his or her music stand, all marked up and ready to be played. There is no one composer of the legal score for a data security performance. The company must compose its own score based on laws, standards, and guidance that are, simultaneously, vague, too broadly written to follow, written in overwhelming detail, filled with dissonant notes, and variable locally, nationally, and internationally. This makes the score arduous and expensive to compose and learn and, as any hacker knows, perfection is not possible.

Hence the role of the conductor. A conductor who can glean— directly or indirectly through section chairs—the business, data flows, and laws governing each of the sections making up the company’s orchestra has the best chance of creating the most compliant data security symphony.

The following questions are intended to help internal counsel as conductor or section chairs compose and orchestrate the data security music their company must play.

What Law and Standards Apply to Each Section, Movement, or the Overall Symphony?

Unlike composers, legislatures and regulators tend to dictate in very broad strokes how data security must operate because one size will not fit all. What works today might not work tomorrow. A data security symphony is more like a greatest hits evening (i.e., a hodgepodge of content that must be cobbled together based on a company’s particular circumstances). U.S. data security laws are made up of non-uniform federal, state, and local requirements that vary by industry sector (e.g., financial, energy, telecom, retail etc.); activity (e.g., using credit reports, accepting commercial or consumer payments, using big data algorithms etc.); data type (e.g., health, financial, biometric, geo-location, children’s etc.); data device (e.g., Internet of Things device, augmented reality device, wearables etc.); and so on.¹

Internal or external legal counsel and consultants can help companies deal with the above locally, nationally, and internationally, but there is no global solution and the initial work will need to be updated as laws, administrations, and data security threats change. The scope and complexity of this endeavor is obvious and procrastination can be particularly deadly. Experience a data security breach triggering laws in almost all states and an increasing number of foreign countries, receive a ransomware threat for company data that was not appropriately backed up, or discover that company crown jewels such as intellectual property, trade secrets, or business documents have been hacked, and any procrastination can result in a crushing reality with long term consequences (such as 20-year regulatory orders).

Examples of Selected, General Starting Points

• General. With respect to generic data security programs, the National Institute of Standards and Technology (NIST) provides a federal framework for reasonable security² that many companies like to use—if only by analogy. However, the Federal Trade Commission (FTC) has warned that the NIST Framework is not a cure-all, at least for companies subject to FTC jurisdiction.³ For those companies, FTC staff has prepared a general guide about FTC enforcement orders and has begun a blog to give businesses a heads-up about what the FTC views as unreasonable security.⁴ For companies tempted to ignore these orders and guidance as not relevant because they are not actual law or regulation, note that, legally or not, the FTC has spent over a decade creating its privacy and data security regime just that way.⁵
• State. Some state laws essentially require reasonable data security while others are very specific, such as New York rules for financial institutions. Some of the wording should not be taken at face value, (i.e., often there will purport to be hidden mandates such as in California).⁶
• Sector specific. Companies governed by sector-specific laws, such as members of the banking, securities, insurance, energy, telecom, and healthcare sectors, may wish to start by dealing with their federal and state sector-specific laws. Although sector is usually a reference to an industry sector, each sector of activities, data, or devices, etc. can also have starting points (such as FTC guidance on security for connected items in the Internet of Things).⁷

What Topic or Data Specific Rules Apply?

Reasonable data security goes beyond protection of obvious data such as crown jewels and personal information. It also extends to arcane and new activities and devices. For example:

• Employers who directly credit employee paychecks to their bank accounts are governed by payment system rules privately published by the National Automated Clearing House Association (NACHA),⁸ and those rules have data security requirements and data breach notice guidance.
• Manufacturers, retailers, service providers, and other companies involved in the Internet of Things (e.g., smart televisions), will not only need to be designed with security in mind⁹ but also pursuant to device-specific laws going beyond security.¹⁰
• Companies using biometric data need to locate and comply with laws defining and concerning such data. The fact that security might be improved with biometric data such as an iris scan does not decrease compliance obligations—to the contrary, solutions involving sensitive data tend to increase them.¹¹

What about Third Parties and Contracts?

Governmental laws or guidance applicable to your company set the beat for data security music but contracts will impact it. Internal counsel should create (or cause to be created) an offensive and defensive contracting strategy for employees, service providers, suppliers, and essentially anyone else with access (physical or electronic) to company premises, systems, data, or other information. This largely is not optional. For example, the California law noted above that requires businesses to have reasonable data security also requires the businesses to trickle down-up-or-over that obligation to third parties via contract.¹²

Practice Tips

• Review the contract to see if it supports the sales pitch. Even if the company hires a third party precisely because that party holds itself out as being able to provide security for a complex area (e.g., third-party token provider for a retailer trying to comply with payment industry rules), the contract actually offered to the company often will not stand behind the touted solution or even the third party’s Payment Card Industry (PCI) compliance role. The practice tip is to read and renegotiate the contract, or attempt to find another provider.
  Social network contracts¹³ provide another example. Assume internal counsel’s company provides an app, website, or Internet of Things device that collects personal information from children. The company likely knows about the need for compliance with Children’s Online Privacy Protection Act or similar state laws,¹⁴ but might assume that social network or data analytic companies that collect data for a living will take care of their own compliance. Often that is not the case, however. More typically, the social network or data analytic contract allocates compliance to the company or might require the company to take particular steps. The practice tip is the same as above, but with an additional tip: work with the IT section so that it will seek legal review of the social network and analytics contracts before thirdparty technology is allowed to take or receive data.
• Be skeptical of the actual wording in otherwise required contracts. When the company is on the receiving end of a third party’s data security clause, don’t believe the argument that the law requires the third party’s wording. The law might require a contract, but not the particular wording or risk allocation. For example, the federal Gramm-Leach-Bliley Act (GLBA) requires financial institutions (FI) to have GLBA security, but a contract requiring the company “to comply with the GLBA” is a trap. Each FI must create a very detailed, custom security program for itself, and the company cannot know what that custom program actually requires. The company might be able to comply with a reviewable rider narrowly setting forth exactly what the FI needs the company to do, however.
• Fill out the Data Security Breach Response Plan appendices. Read and work the data security contractual obligations into the company’s Data Security Breach Response Plan before a breach can occur. For example, if a credit card data breach occurs and the company grabs its Data Security Breach Response Plan, will the appendix for “payment card breaches” still be empty or will it be fully fleshed out with the exact reporting requirements and deadlines? If it’s still empty, it’s almost a certainty that by the time the company or its counsel reads through the myriad rules and policies (which are changing at ever-shortening intervals), it will have missed a deadline and be exposed to higher penalties.

This will be so even if the company is working closely with its merchant bank representative (including one who fails to mention which brands are outside the scope of what the representative is doing).

How Do Company Policies Mesh with Its Actual Security Program

In 2014 the Heartbleed virus essentially invalidated Secure Sockets Layer (SSL) as a reasonable encryption method and by 2015, the Payment Card Industry Data Security Standard (PCI DSS) warned against its use.¹⁵ Yet today in 2017, it still is rather common to see a website privacy policy touting the security of SSL encryption.¹⁶ If the IT section stopped using SSL but forgot to tell the section charged with amending the privacy policy, that lack of coordination can create dissonance in the compliance music.

Another example is the IT group that creates security for company emails accessed by employee-owned smartphones by implementing a kill-switch solution allowing the company to wipe all content if the phone is stolen or lost. Many companies have that solution, but how many IT departments worked with their legal departments to back it with an appropriate contract between the company and employee?

A successful conductor needs to be in a position to learn what each section of its data security orchestra is actually doing so that needed harmonization can be created.

What Documentation is Advisable?

Documentation of a company’s data security program can buttress its data security efforts even when not literally required. Lack of documentation is taken by some regulators as a warning signal that the company is not serious about data security.

Practice Tips

Attempt to:

• Create required or otherwise reasonable documentation that is relevant to the company’s legal and business circumstances.
• Avoid over-promising. For example, in a Data Security Breach Response plan, why say that the core planning group “must” adhere to the plan so as to “ensure” “full” compliance with applicable laws? Few breaches will allow the group to meet those mandates. A more realistic approach, when legally possible, would be to require the group to make reasonable efforts to meet the plan in light of the urgent, ambiguous, legal, and technological circumstances of the particular data emergency at issue, and allow the group to make good faith judgments.

What about Acquisitions?

Whether a company wants to acquire other companies or be acquired, data security is an issue. Poor data security can decrease the purchase price and increase indemnities and holdbacks if your company is being acquired. If your company is the acquirer, development of due diligence checklists to deal with the range of data security issues (as well as the raft of other new due diligence issues created by our digital economy) is a must in order to understand what risks the acquirer may be buying. Typical M&A checklists often do not deal with this topic at all or appropriately.

In 2011, the U.S. Securities and Exchange Commission (SEC) issued guidance regarding disclosure obligations of publicly traded companies relating to cybersecurity risks and cyber incidents.¹⁷ As explained by the SEC, “material information regarding cybersecurity risks and cyber incidents is required to be disclosed when necessary in order to make other required disclosures, in light of the circumstances under which they are made, not misleading.” The SEC guidance officially brought certain security risks into the realm of SEC-required disclosures. Similar issues exist for non-reporting companies and the SEC materials can be helpful, if only by analogy, when creating a data security program.

To illustrate, does the company’s standard due diligence checklist ask about what material data security incidents the target has experienced but did not disclose to data subjects or regulators, and could that nondisclosure create a reportable issue for a public company? Regardless of reporting rules, does that nondisclosure create another risk the acquirer needs to consider before proceeding with the deal? In recent years, the SEC has been buttressing its guidance and data security expectations with data security questionnaires and examination signals that can be worked into any due diligence checklist. Of course, that will not be the end of the checklist.

When Can Internal Counsel Declare Victory?

Partial victory can be declared when a data security program is developed and finished based on appropriate background and compliance work. Unfortunately, final victory can never be declared. Data security requirements are ambiguous in the first place and ever-evolving.

Non-privacy/security lawyers correctly laugh at the thought of a regulator purporting to use anything other than formal law or regulations to define existing or future legal obligations of companies, but the reality is not funny. Legal or not, that is how many regulators are regulating and the jury is still out on whether and the extent to which that approach is legal. In the meantime, it is the regulator that gets to decide whether to bring an enforcement action.

Conclusion

Data security is not a single piece of music. It is a symphony—a large, multi-movement work involving all sections and subsections of the orchestra and maneuvering through a full range of interpretation, balance, tempo, and phrasing that must change as laws and technology change. Unlike a real symphony, the data security symphony each company must play has not already been written. Each company must compose its own version based on applicable laws relevant to its particular venues, industry, activities, products, data, or other information. The role of the company’s internal counsel can be to conduct the entire orchestra and chair the various sections.

Holly K. Towle is the author of The Law of Electronic Commercial Transactions, an information-rich treatise regarding digital economy legal issues about which she speaks and consults. Before her recent retirement, Ms. Towle spent her career as a partner with K&L Gates LLP, an international law firm, where she focused on electronic business issues, including data privacy and security, big data, artificial intelligence, consumer protection and payment system compliance, e-contracting structures, and legal distinctions between information and goods or services.

To find this article in Lexis Practice Advisor, follow this research path:

RESEARCH PATH : Corporate Counsel > Cybersecurity > Planning for and Managing a Data Breach > Articles

1. See generally Towle, The Law of Electronic Commercial Transactions, https://store.lexisnexis.com/categories/product/the-law-of-electronic-commercial-transactions-skuusSku-us-F53, at Chapter 6 (Attribution: Identifying the Parties), Chapter 10 (Liability for Informational Content), Chapter 12 (Privacy and Data Protection), Chapter 15 (Identity Theft), and Chapter 16 (Data Security) etc. 2. See NIST Cybersecurity Framework (https://www.nist.gov/cyberframework). See also NIST Baldrige Cybersecurity Excellence Builder (https://www.nist.gov/sites/default/files/documents/2016/09/15/baldrige-cybersecurity-excellence-builder-draft-09.2016.pdf), a self-assessment tool which is intended to blend two widely used NIST resources: the organizational performance evaluation strategies from the Baldrige Performance Excellence Program (https://www.nist.gov/baldrige) and the risk management mechanisms of the NIST Cybersecurity Framework. For more information about FTC requirements as indicated in its enforcement actions and a new blog, see Endnote 5. 3.The FTC has noted this question (emphasis added): “If I comply with the NIST Cybersecurity Framework, am I complying with what the FTC requires?” The FTC was not willing to answer “Yes,” although it did admit that the Framework is consistent with the FTC’s approach: With that bit of background on the FTC’s data security program, let’s get back to the question, “If I comply with the Framework, am I complying with what the FTC requires?” The Framework is not, and isn’t intended to be, a standard or checklist. It’s meant to be used by an organization to determine its current cybersecurity capabilities, set individual goals, and establish a plan for improving and maintaining a cybersecurity program, but it doesn’t include specific requirements or elements. In this respect, there’s really no such thing as “complying with the Framework.” Instead, it’s important to remember that the Framework is about risk assessment and mitigation. In this regard, the Framework and the FTC’s approach are fully consistent: The types of things the Framework calls for organizations to evaluate are the types of things the FTC has been evaluating for years in its Section 5 enforcement to determine whether a company’s data security and its processes are reasonable. By identifying different risk management practices and defining different levels of implementation, the NIST Framework takes a similar approach to the FTC’s long-standing Section 5 enforcement. See https://www.ftc.gov/news-events/blogs/business-blog/2016/08/nist-cybersecurity-framework-ftc?utm_source=govdelivery. 4. See “Start with Security: A Guide for Businesses” (https://www.ftc.gov/tips-advice/business-center/guidance/start-security-guide-business) and “Stick with Security” (https://www.ftc.gov/news-events/blogs/business-blog/2017/07/stick-security-insights-ftc-investigations?utm_source=govdelivery). 5. Strong arguments can be made that the FTC has exceeded and is exceeding its legal authority, but it has had some initial success in litigation regarding that issue, and it is expensive and risky to litigate against a regulator with the power to impose material penalties. Some companies take a two-pronged approach—heeding FTC warnings just in case it is proceeding legally, but also supporting efforts to require the FTC to heed applicable law. See for example, Chapter 12.16[3], Towle, The Law of Electronic Commercial Transactions, https://store.lexisnexis.com/categories/product/the-law-of-electronic-commercial-transactions-skuusSku-us-F53. 6. See Cal. Civ. Code Sec. 1798.81.5 (b). Using defined terms, it literally creates a very general obligation: (b) A business that owns or licenses or maintains personal information about a California resident shall implement and maintain reasonable security procedures and practices appropriate to the nature of the information, to protect the personal information from unauthorized access, destruction, use, modification, or disclosure. However, hidden in a report by the California Attorney General on data breaches, the California Attorney General purported to interpret it as including 20 very detailed and material controls. See “California Data Breach Report February 2016” (https://oag.ca.gov/breachreport2016, emphasis added) (stating that the statute requiring businesses to use “reasonable security” is a set of controls from an industry standard. The following statement is made in the “Recommendations” section of the Executive Summary: “The 20 controls in the Center for Internet Security’s Critical Security Controls identify a minimum level of information security that all organizations that collect or maintain personal information should meet. The failure to implement all the Controls that apply to an organization’s environment constitutes a lack of reasonable security.” 7. See for example, the FTC’s “Careful Connections, Building Things in the Internet of Things” (https://www.ftc.gov/system/files/documents/plain-language/pdf0199-carefulconnections-buildingsecurityinternetofthings.pdf)(2015) and Footnote 9. 8. See https://www.nacha.org/rules. 9. See for example, NIST Special Publication 800-160 advising those involved with developing Internet-connected systems and devices to build security safeguards directly into their products and then to consider security at every lifecycle stage (http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160.pdf). See also FTC Staff Report Internet of Things: Privacy & Security in a Connected World, 7-10 (Jan. 2015), (https://www.ftc.gov/system/files/documents/reports/federal-trade-commission-staff-report-november-2013-workshop-entitled-internetthings-privacy/150127iotrpt.pdf), and an illustrative FTC enforcement action, FTC v. D-Link Corporation et.al, FTC Matter/File Number: 132 3157 (alleging D-Link failed to take reasonable steps to secure its routers and Internet Protocol cameras, potentially compromising sensitive consumer information). 10. See Chapter 12.23 (discussing California law mandating particular contract formation rules for televisions with voice recognition features) and Chapter 10.14 (consumer Internet of Things issues) of Towle, The Law of Electronic Commercial Transactions, https://store.lexisnexis.com/categories/product/the-law-of-electronic-commercial-transactions-skuusSku-us-F53. 11. For an example of a biometric statute, see Illinois Biometric Information Privacy Act (BIPA), 740 Ill. Comp.Stat. Ann. 14/1, et seq. (the introduction to this act says: “The public welfare, security, and safety will be served by regulating the collection, use, safeguarding, handling, storage, retention, and destruction of biometric identifiers and information”). 12. See for example, Cal. Civ. Code Sec. 1798.81.5 (c): (c) A business that discloses personal information about a California resident pursuant to a contract with a nonaffiliated third party that is not subject to subdivision (b) shall require by contract that the third party implement and maintain reasonable security procedures and practices appropriate to the nature of the information, to protect the personal information from unauthorized access, destruction, use, modification, or disclosure. Several FTC enforcement orders also require contracts, including with remote parties. 13. For discussion of what these contracts are and where they can be found, see Chapter 10.14[1] Towle, The Law of Electronic Commercial Transactions, https://store.lexisnexis.com/categories/product/the-law-of-electroniccommercial-transactions-skuusSku-us-F53). 14. For a discussion of this topic, see Chapter 12.11 (Children’s Online Privacy Protection Act and State Statues Regarding Children or Other Minors) of Towle, The Law of Electronic Commercial Transactions, https://store.lexisnexis.com/categories/product/the-law-of-electronic-commercial-transactions-skuusSku-us-F53. 15. By analogy, see for example, PCI DSS, version 3.1 (removed from examples of acceptable encryption, SSL and early Transport Layer Security (TLS)). The current version of PCI DSS, version 3.2 required service providers to provide a secure offering by June 2016 and assumes that all entities will cease use of SSL and TLS 1.0 as a security control by June 30, 2018. An industry blog says this: “Despite the 2018 deadline, you should move to replace these protocols as quickly as possible. Of the top 10 critical vulnerabilities identified through penetration testing by Trustwave in 2015, SSL protocol vulnerabilities ranked first.” Trustwave blog 4/18/16 at https://www.trustwave.com/Resources/Trustwave-Blog/What-You-Need-to-Know-About-PCI-DSS-3-2-(and-Why-Security-Comes-First)/?mkt_tok=eyJpIjoiWldOaU1XVmxZVGcwTnpVMiIsInQiOiIwQ01zNHBVMWNXckNWZEtKR0VcLzJIaTRaYW93ejlmdU5xZFJGMGNmUFBTbytEeUloaDR6MkpXNTRMVG9iblV5WDdcL3IrZ0N1UlJoTTJ4ZHNiZ2lcL1VZWGtOeFFibUhPYXR6bkVncFRmVmpSMD0ifQ%3D%3D. 16. A random search in 2017 revealed this example in a privacy policy: “The security of your personal information is of the utmost importance to [X]. [X] only transmits personal information, including sensitive information (such as credit cards), using secure sockets layer technology (SSL).” 17. See Disclosure Guidance: Topic No. 2, Cybersecurity, Div. of Corp. Finance SEC (10/13/11) (guidance re disclosure obligations relating to cybersecurity risks and cyber incidents) (http://www.sec.gov/divisions/corpfin/guidance/cfguidance-topic2.htm).