Introduction

In the first article in this series, we looked at security concerns related to clickwrap and shrinkwrap agreements, used by vendors for mass-market licenses and service agreements. In these cases, no negotiations are involved. If you want what the vendor is selling, you are required to agree to "a one size fits all" agreement, including whatever provisions it contains, if any, that pertain to information security. This type of agreement is typical of the licensing agreements that individual users and small organizations enter into.

This article looks at a situation that is more typical for commercial users, one in which negotiations between vendors and service providers and their users concerning licensing and services agreements are commonplace and expected, and discusses why it is helpful, and usually essential, to have information security professionals participate in those negotiations.

Why You Need a Seat at the Table

Information technology transactions involve two principal areas: the functionality one party is providing (i.e., the software or services) and what the other party must do or pay to obtain access to that functionality. The basic information technology, whether it is a license or an agreement for services brings together a party that needs to have data transformed with the party that will make that transformation possible for a price or other consideration.

Proceeding without a secure environment would put at least one of the parties at risk, but that fact often seems so obvious to the people who make deals that no discussion of it appears necessary. As a result, information security concerns are unlikely to be the primary focus of contract negotiations, except where the technology involved is expressly intended to address a security related concern. It is all too common for business people to treat information security as a "given."

But if it is your job to secure the environment for the transaction, you know that security does not take care of itself. You take care of it. Once you have defined the transaction's security needs, the next step is to ensure that those needs will be met. A written agreement addressing those security needs is essential. Why? Well, without getting deeper into contract law than we need to, let's just say that if the parties ever disagree, it's what the agreement states, not what was said in the security meeting, that will count. In short, if your security needs require that your vendor or client do or refrain from doing something, if the agreement does not reflect that requirement, your organization is probably not protected.

Specific provisions for appropriate information security belong in most, if not all, information technology agreements because security is no less critical to the success of such transactions than the technology itself or the payment terms. So the job of information security professionals includes ensuring that their voice is heard during contract negotiations and that their input is reflected appropriately in the agreements for the transaction.

The bottom line is that neither information security professionals nor legal counsel perform their functions in information technology transactions fully unless they work together. Information security professionals should be actively involved with business decision makers and legal counsel throughout the course of negotiations and contract preparation. Without input from information security professionals and contract language that reflects it, the enterprise is likely to be exposed to unnecessary legal and technological risk.

Lawyers Are Your Allies

Lawyers and security professionals are often concerned with the same risks, although they examine those risks from different perspectives and describe them using different jargon. There is often a legal aspect to security issues, and the converse is also frequently true. What lawyers see as exposure to prospective liability resulting from the inadequate protection of user data, security professionals see as risks of intrusion. As an example, the Uniform Trade Secrets Act extends trade secret protection to information that is, among other things, "the subject of efforts that are reasonable under the circumstances to maintain its secrecy." (Uniform Trade Secrets Act, Section 1(4)). In the context of information technology, when lawyers consider what is and is not "reasonable under the circumstances" they are considering, in part, access controls put in place by information security professionals. Common points of concern for legal and information security professionals include avoiding exposure to viruses and other destructive code and, more generally, minimizing the potential for any unauthorized access to, or alteration or transmission of, confidential or proprietary data.

Security professionals and counsel both inform and advise the business people who run transactions of the risks those transactions involve. Once a business person has decided to proceed with a transaction, the goal of both information security and legal professionals is to minimize the associated risks. As a technology professional, you know how to find the risks that are present in the technology architecture of a product or service. In this respect, you may able to advise the organization about security risks that may be inherent in the software or service; but, as noted above, the concerns you have may not be adequately addressed or resolved unless and until your input is reflected in the agreement. Part of your counsel's job is to develop the language necessary to do that.

Getting the Agreement into Shape

The simplest way to get security requirements into an agreement is to insert a provision specifying them. But a single provision stuck into an otherwise unmodified agreement is unlikely to be effective. Your counsel is likely to ask you to read through the whole proposed agreement, with particular attention to how proposed security provisions interact with three important sections of the agreement, namely: the representations, warranties and covenants (the technical distinctions between representations, warranties and covenants are not important for our purposes.), the disclaimers, and the limitations of liability.  These terms that refer to a series of statements and promises that the parties make to each other that bear on the circumstances in which the basic deal takes place. You should always consult with counsel whenever you need to interpret a legal document. That said, it is helpful to have some background as to how these different sections of agreements interact.

What Do IT Agreements Do?

Let's consider a basic software license for which the user will pay the vendor a lump sum annual fee. This is a very straightforward deal and, of course, the agreement will set out what software or services are being provided and what payment is expected for it. Simple. But even so, there are many things that the parties would like to know about each other that relate to the basic transaction. The user would like to know that the vendor has the right to license the software, and that no violations of any other party's rights, such as intellectual property rights or rights of exclusivity under contract, will result from either executing the agreement or from the contemplated use of the software.

With respect to security, the user would like to know that the licensed software or services contain no viruses, time bombs, or other destructive code, and that the software does nothing more or less than the data transformation the user has in mind. For its part, the vendor wants assurances that, at a minimum, the user will use the software as represented and can pay the annual fee. These concerns are typically addressed in a series of statements and promises that the parties make to each other that bear on the circumstances in which basic deal takes place (the Representations, Warranties and Covenants, the Disclaimers, and the Limitations of Liability referred to previously).

Disclaimers

Disclaimers are statements of what the parties do not promise each other, and function as the counterpart to representations, warranties, and covenants. In theory, disclaimers make sure that everyone knows where they stand. But in practice, carelessly drafted disclaimers cause confusion about obligations that appear in other provisions of an agreement and may weaken or negate those provisions. Vague and overly broad disclaimers may also raise security concerns. Disclaiming (expressly refusing to promise) that code or a service will function as expected causes tension with a representation and warranty (statement and promise) that the software is virus-free or that it will work consistently with pre-existing security measures the user employs.

Limitations of Liability

As the name implies, these provisions restrict the liabilities that the parties will have to one another in the event that their agreement is breached. Limitations of liability may be expressed in the type of relief that will be available. For example, it is common to limit liability to compensatory damages but to exclude punitive damages. Express limitations of financial liability, with stated dollar amounts, are also common. The relevance to security professionals is clear. No vendor can prevent all security breaches and certain attacks cannot reasonably be anticipated, so imposing unlimited liability for such attacks on vendors is unfair. On the other hand, users need recourse against a vendor's negligent or knowing acts or omissions that cause breakdowns in security. When a vendor's acts or omissions put their users' security at risk, no limitation of liability seems appropriate. Striking the right balance in limiting liability depends on the commercial and technological specifics of each deal. The basic point is not to allow the other party to limit liability for its important security-related obligations without making sure that the business decision makers understand and accept the associated risks.

Providing for Security

With this background, let's turn to the preparation of a specific security provision. It turns out that, for two reasons, this can be a troublesome task. First, there is inherent tension between the interests of technology providers and their users in assigning contractual responsibility for information security. Vendors cannot control what their users do and they are understandably unwilling to take responsibility for security problems caused by users. Users, however, want vendors to furnish solutions that require minimal commitment of user's resources or disruption to its operations. Users take the position, again understandably, that security risks caused by the installation and operation of the vendor's technology ought to be the vendor's responsibility. This dynamic means that in nearly every transaction, a line has to be drawn that divides the security aspects of the relationship for a which a vendor and its user will each have responsibility. The best people to fix this boundary in each case are the information security professionals who work for the vendor and the user, respectively.

The second issue is that security threats and the appropriate responses to them evolve over time but agreements do not. Agreements typically run for several years or they may have a one-year term that renews automatically. Once signed, the agreement will be filed away and, barring a dispute between the parties, the agreement may not see the light of day for years, if ever. Even if the agreement contains a provision specifying the best current information security technology and practices at the outset, several years later, the sophistication of both bad actors (such as mailicious hackers and virus writers) and the people who defend against them will have increased, but the contract will still call only for what are, by then, old precautions that are unlikely to still be adequate.

Another side of this issue is that successful transactions lead to the creation of information assets that gain value over time. Several years after the launch of an information service, its user base will be larger and more demographically consistent than at the time it was launched, and it is, therefore, a more attractive target. Protecting the database of such user information becomes progressively more difficult and important over time. The agreement governing any transaction that contemplates the creation of information assets that are expected to grow in value ought to provide for information security that evolves accordingly. This dynamic illustrates the value of routine interaction between counsel and information security professionals in the preparation of information technology agreements.

So, with these issues and dynamics in mind, what goes into a sound provision for information security? Vendors are unlikely to admit it, but they are in a better position than their users to respond to the changing security needs their software or services impose. That means that the contractual burden of the evolutionary character of security provisions belongs with them, not with users. So a basic information security provision provides for an overall level of information security, as negotiated between the parties, depending on the circumstances. It should also make particular note of the sensitivity of any information involved and any regulatory burdens associated with that information. The vendors' obligation to maintain that agreed-upon level of information security should be defined as both the adoption and use of acceptable security technology and practices at the time the agreement is executed andthe additional, ongoing duty to supplement those measures, as circumstances warrant, to maintain the level of security agreed upon as time goes by. This approach exposes vendors to potential liability for the failure, at any time while the agreement remains in force, to adopt and use new security devices as new threats become apparent or as new security technology or practices evolve.

This approach makes vendors nervous; but what they tend to be nervous about is prospective liability for security breakdowns caused by users. As long as the evolutionary character of the vendors' obligations is confined to its own software or services, this approach is fair, and responsible vendors know it. These are the vendors who are aware that as a matter of basic competitiveness and customer service, they have to keep up with information security developments in any event. All this provision does is require them to do for a user what they know they are supposed to be doing anyway.

For their part, vendors will understandably want to define the scope of their liability for information security breaches with precision and to clearly exclude responsibility for risks users create. The great benefit of this arrangement is that it permits information security for the transaction to evolve continuously and automatically, without the need to modify the agreement or to incur the associated legal expenses.

There are other issues to be considered. Vendors have vendors of their own. As a user, it is not unusual to find that your service provider has service providers of its own, and that they may depend on still other parties to deliver what is, from the user's perspective, a single service. As a vendor, you may find that your user has users. So as either a vendor or a user, certain transactions involve the security implications of dealing with entities that the other party brings to the table. These other entities are typically not signatories to the agreement, and your security language should take that into account. Each party should take responsibility for information security risks caused by the acts or omissions of any other entities it involves in the transaction.

Other Legal Considerations

Finally, for most of this article, we have been discussing the law of contract, which generally permits parties to hammer out whatever deal they want. There are other sources of law to be considered. The Computer Fraud and Abuse Act, 18 U.S.C. § 1030 (the "CFAA"), the principal federal anti-hacking statute in the United States, has been used to supplement contract claims for defective software, on the theory that the knowing design, manufacture, distribution and sale of that software, using ordinary avenues of commerce for information technology, caused "damage" under the CFAA's broad definition of that term. (Shaw v. Toshiba America Information Systems, Inc., 91 F.Supp.2d 926 (E.D. Texas 1999)). The CFAA has already been used as a vehicle for claims for liability based on the inclusion of destructive code. (North Texas Preventative Imaging v. Eisenberg, 1996 WL 1359212 (C.D. Cal. August 19, 1996)) (In this case, the destructive code was a time bomb). It appears to be only a matter of time before the CFAA is invoked to seek recovery from a vendor for providing software infected with a virus or for a service that causes a loss of security. See 18 U.S.C. §§ 1030 (a)(5)(A)-(C). Because the CFAA is in part, a criminal statute, the consequences of a violation can be significant.

Once a business decision has been made to run certain risks, the job of both attorneys and security professionals is to find and use all the approaches available to minimize those risks. That includes maximizing the protections the agreement for the transaction can provide. Information security professionals and counsel both do a better job when they work together to reach this common goal. The enterprise that each serves reaps the benefits of their cooperation.

Steven Robinson is an intellectual property and information technology attorney practicing in New York. Mr. Robinson is a professor of technology management at Stevens Institute of Technology, and a former consultant to the Technology, Intellectual Property and Privacy practice in the Office of the General Counsel of Merrill Lynch. He has specialized in intellectual property and information technology matters since 1992, and in 1998, he received a grant from the United States Department of State to teach intellectual property and Internet law abroad.