The Legal Defensibility Era - InfoLawGroup

The Legal Defensibility Era | David NavettaISSA Journal | May 2010Contractual obligations imposed on an organizationMany organizations face data security requirements arisingout of contracts with third parties. PCI is a perfect example– in order to accept credit cards organizations typically mustcontractually agree to maintain PCI-compliant controls.Moreover, some data security and privacy laws require companiesto contractually impose certain security obligationson others. From a legal defensibility point of view the firstissue is whether the organization’s security actually lives upto these contractual obligations, and if so, whether the legalliability associated with a breach of contract is tolerable. Thisrequires a legal interpretation of those obligations and thepotential liability faced by the company, which then mustbe taken into account when implementing security. It alsorequires careful review and negotiation of these contractsto ensure that the organization is taking on the appropriateamount of risk and liability.Data security of service providers/outsourced relationshipsIncreasingly organizations of all sizes and types are relyingon third parties to store, process, and transmit data on theirbehalf. Whether in a “cloud” environment or a dedicatedhosting/processing setting, customers can be held legally liablefor security breaches or the non-compliant security oftheir service providers or partners. Legal defensibility in thiscontext focuses on two areas: due diligence and vendor management,and data security contractual requirements imposedon service providers.When selecting a service provider, a key legal issue is whetherthe customer adequately vetted the security of the serviceprovider to ensure that it meets legal requirements and hasreasonable security. In this context, from a legal standpoint,organizations should consider their service providers’ informationsecurity an extension of their own internal informationsecurity set up. Potential liability may exist if the organizationfails to vet (or improperly vets) its service provider, orworks with a service provider whose security is weaker than,or does not match up with, the organization’s internal security.The contract between the vendor and the customer is veryimportant in terms of legal defensibility. The contract shouldreflect relevant data security obligations and compliancewith relevant data security and privacy laws. Security andlegal should work together to contractually impose certaincontrols on the service provider that are necessary to meetthese legal obligations. Moreover, the contract should addresssecurity assessment rights, breach response, and transfer ofrisk of loss.The concept of risk and the lawAs any security professional knows risk assessment is a keyfactor in analyzing security risk and choosing controls tomitigate risk to a reasonable level. The concept of risk is alsoprevalent in the law. Under common law, some courts considerrisk in determining whether a legal duty exists (including aduty to implement reasonable security controls) and whetheran organization has satisfied that duty. Judge Learned Hand’sformula is as follows:If the probability be called P; the injury, L; and the burden,B; liability depends upon whether B is less than Lmultiplied by P: i.e., whether B < PL.The concept of risk is important for determining whether anorganization has implemented reasonable security. At a bareminimum this means that organizations should implementthose controls that significantly reduce risk but are relativelyinexpensive. On the other end of the spectrum, the law recognizesthat risk need not be reduced to zero where the cost/burden would be overwhelming. In a legal defensibility paradigmrisk, as viewed under common law and case law, shouldbe taken into account and legal arguments developed to establishthat such risk was adequately mitigated.In addition, many data security laws include risk factors thatallow organizations to implement “less” security if they poseless risk or have less resources, including, for example, GLBand Massachusetts’s 201 CMR 17.00. PCI also addresses theconcept of risk in its allowance of compensating controls.The concept of risk factors also must be understood in thelegal context. Lawyers must interpret the meaning of the riskfactors based on case law and statutory construction, andhow they are weighed against each other, and construct argumentswhy their organization poses less risk and thereforeneed not implement the more rigorous data security controls.Under a legal defensibility approach the meaning of these riskfactors in the legal context should feed into the data securitychoices made by an organization. The legal justification oflower risk should be documented to help establish compliancein the event of litigation or a regulatory action.Information security standardsImplementing security that is consistent with various securitystandards may be helpful in reducing legal risk. It is veryimportant for an organization to understand how courts lookat standards and how they relate to legal liability. Complyingwith recognized standards such as ISO 27002 or NIST 800-53may be viewed favorably by courts because both are establishedstandards created by recognized standards bodies, andthey establish frameworks based on principles that are commonlyaccepted in the security world. Complying with thesestandards instead of (or in addition to) using a purely ad hocapproach (and even better being certified by a third party ascompliant) can carry significant weight in a court.Beyond general standards, industry standards may be applicableto an organization that is part of a particular industryor a particular peer group within an industry. Again, the keyfrom a legal defensibility point of view is understanding thatmany courts view industry standards as a floor for purposesof analyzing reasonable security. In fact, some courts haveruled that an entire industry may be acting unreasonably,and not within the standard of care. As such, in developing alegally defensible security program, organizations may haveto go beyond industry standards.©2010 Information Systems Security Association • www.issa.org • editor@issa.org • Permission for author use only.15

The Legal Defensibility Era | David NavettaISSA Journal | May 2010terms requiring certain controls/levels of security and transferringrisk of loss should something go wrong.ConclusionOverall, legal defensibility is another important factor forsecurity professionals and organizations to consider whenimplementing and maintaining an information security program.However, it cannot be stressed enough that the generalgoal of “good security” cannot and should not be replacedwith a narrow focus on reducing legal risk. In fact, good securityand legal defensibility go hand-and-hand with goodsecurity being a strong indicator of legal defensibility. Theprocesses of building a security program and reducing legalrisk should be viewed and treated as complimentary.Nonetheless, failure to recognize the overlap between thelaw and security and to prepare for the time when an organization’ssecurity will be scrutinized in an entirely differentworld (e.g., the legal world) may be detrimental. Now isthe time for security professionals and lawyers to get togetherand begin the collaboration that will be necessary to dealwith legal risk and information security holistically. As thelegal risk environment becomes more complex and liabilityrisk more common, implementing a legal defensibility strategywill continue to grow in importance.About the AuthorDavid Navetta, Esq., CIPP, is one of thefounding partners of the Information LawGroup (www.infolawgroup.com). Davidhas practiced law for over twelve years, includingtechnology, privacy, informationsecurity, and intellectual property law andcurrently serves as a co-chair of the AmericanBar Association’s Information SecurityCommittee. He has spoken and written frequently concerningtechnology, privacy, and data security legal issues andcan bereached at dnavetta@infolawgroup.com.©2010 Information Systems Security Association • www.issa.org • editor@issa.org • Permission for author use only.17