Standards and Frameworks as Contract Measures of Performance

Especially in technology-driven agreements, contracting parties aim to set performance measures to objectively assess whether the vendor meets expectations and to enable remedies if not. However, many requirements lack clear metrics and rely on vague terms such as "industry standards" or "commercially reasonable". Vendors often publish their own standards online and can change them at will. These ambiguities often lead to disputes over what the contract’s performance standard truly was.

One way to address these concerns is to adopt technical standards and frameworks developed by trusted third parties to align expectations. These frameworks eliminate the need for parties to create their own terminology and can serve as a metric for reasonable expectations. Widely accepted, industry-respected standards, especially those used in disputes, make measuring contractual performance more objective and trustworthy for both the vendor and the buyer.

Using publicly issued frameworks and standards has pitfalls, like standards that allow a performance range and require parties to agree on acceptable levels in advance. Many are written from the buyer's perspective, so referencing them during vendor performance may require careful wording to clarify that the vendor is fulfilling the requirements, even if the vendor is not the true beneficiary. Nonetheless, using resources vetted by outside experts increases the likelihood of achieving expected results in a transaction.

Vendors often seek ambiguity and may downplay the importance of published standards, using vagueness to avoid accountability in disputes. Buyers should have knowledgeable personnel who can confirm the relevance of these frameworks and ensure they serve as the basis for performance expectations, despite vendor resistance.

Frameworks

A framework is a document that outlines key issues, why they matter, the terminology used in discussions, and the metrics for measurement. Often, simple technology doesn't need a framework. However, complex modern tech issues, such as privacy, data security, and AI fairness, make it hard to agree on important questions, terminology, measurement, and metrics. Having a common technical framework helps address these questions by providing a mutual basis for discussing performance standards, terminology, and metrics.

A framework is often the most technically detailed document issued by a framework and standards body, and referring to it will help parties avoid much of the technical back-and-forth. But it is vital to remember that frameworks, by themselves, are not prescriptive. At their best, they provide background on a canvas, and users need to determine how to fill in the blanks. Frameworks anticipate variation among users based on domain-relevant factors, such as levels of risk and risk tolerance, capacity to pay, and laws that may set minimum standards. Simply referring to a framework without addressing the open questions is practically no better than citing an undefined industry standard.

Some of the best-known technical frameworks used in the United States are issued by the U.S. National Institute of Standards and Technology (“NIST”), an agency of the U.S. Department of Commerce. In the information technology space, some of its best-known frameworks include the Privacy Framework, Cybersecurity Framework, and Artificial Intelligence Risk Management Framework.

Filling in a Framework

One way to complete a framework is to use it to ensure all relevant issues are covered and to establish a common language between the parties. Subject matter experts from both sides can use the framework as a guide to discuss and agree on the expectations to include in the contract. This approach may be effective when both parties have technically skilled individuals at the bargaining table, the issues are manageable enough not to dampen overall enthusiasm, and the parties hold relatively equal bargaining power and motivation to finalize an agreement. Naturally, both sides must be free to accept what they can live with, given external requirements such as applicable laws.

Rather than hashing out the details (which may be an unending exercise), the parties might choose to use a published third-party technical standard issued by a mutually trusted standards body. Standards, unlike frameworks, are intended to provide, in the issuing body's considered opinion, the correct answers to fill the blanks left by a framework.

The standards issuer may be international, governmental, quasi-governmental, regional, or another industry-recognized standard-setting organization, industrial organization, engineering organization, interest group, consortium, trade association, task force, or any other similar forum or entity. The key is that the standards issuer has the gravitas and expertise to enable both parties to trust the standards as a measure of what is reasonable to expect of each other within the subject matter of the standard. NIST is a well-known issuer of standards, but there are many others that may be used, such as the International Standards Organization (“ISO”) for a variety of subjects, including cybersecurity; the Institute of Electrical and Electronics Engineers (“IEEE”) for electronics and electrical engineering and related disciplines; and the World Wide Web Consortium (“W3C”) for website standards such as accessibility compliance. Some standards can be used only after one party purchases a subscription; others are free to use.

Another type of standard is applicable law. A law may set technical standards that the parties must comply with. If the buyer depends on the vendor to provide a product or service that enables the buyer to comply with its own legal obligations, it is important to bake that obligation into the contract. Be careful not to merely require the vendor to comply with all laws. Often, the vendor itself is not directly subject to the law. Only the buyer is. If the vendor provides a product to the buyer that is not compliant with the buyer’s own legal obligations, the vendor is not in breach of contract, since it had no legal obligation itself. Make sure the reference to the law makes clear that the buyer expects the vendor to provide products and services that permit the buyer to be legally compliant.

Published standards often supplement what may be in a law. Cybersecurity standards, for instance, which must change frequently due to the rapid evolution of data security risks and mitigations, are often used to fill in what a law may simply refer to as reasonable security. The rationale is that one can only be reasonable if one is acting within the bounds of a well-respected standards issuer.

One would hope it would be easy to move between a framework, a technical standard implementing that framework, and all the laws that apply to the same subject matter, with careful cross-referencing so we know which part of a standard or a law addresses any particular part of a framework. That is rare. A reader of a framework often has to search across related standards to find where an issue in the framework might be addressed. Or a law may set out requirements that are fulfilled by following the more detailed provisions in a published standard.

There are community efforts to create crosswalks, which make connections clear without requiring manual searching. A crosswalk is a spreadsheet-like document that lists all the concerns from one document, with each concern in a single row and the corresponding section of the other document shown to the right. NIST has published a number of crosswalks, including one that connects the Privacy Framework and the Cybersecurity Framework, and another that compares NIST’s AI framework with multiple laws that apply to deployers of artificial intelligence tools. None of these crosswalks carries the force of law.

Frameworks and standards can be valuable tools for drafting contracts that capture parties’ bargains on technical requirements if lawyers, businesspeople, and subject-matter experts take the time to use them appropriately. Shorthand references to frameworks, technical standards, or generic industry standards do not yield the same results.