Category Archives: Litigation

The Promise of, and Legal Issues and Challenges With, Blockchain and Distributed Ledger Technology

Posted on by
Reply

[Originally published in December 2016. Updated on April 7, 2018 to clarify the explanation of blockchain and distributed ledger technology and to add more information on the legal risks and challenges.]

Blockchain and distributed ledger technology is poised to revolutionize many aspects of the world around us. It may prove to be as disruptive and innovative of a force as augmented reality. Many people associate “blockchain” with “Bitcoin,” whose meteoric rise as a cryptocurrency has been well reported. However, they are not one and the same. Bitcoin is an application; blockchain and distributed ledger technology are the methods behind it.  But what is it? How might it change the world? And what legal and other risks does it bring?

What is Distributed Ledger Technology and Blockchain?

The Old – Centralized Ledgers

Centralized ledgers (a database, list, or other information record) have played an important role in commerce for millennia, recording information about things such as physical property, intangible property including financial holdings, and other assets. The most recent innovation in centralized ledgers has been the move from physical ledgers (paper, stone tablets, etc.) to digital ledgers stored electronically. A “centralized ledger” is a ledger maintained and administered in a single, central location (e.g., a computer database stored on a server) accessible by anyone without use of access controls (public) or through an access control layer by persons or organizations with valid login credentials (permissive). This is a “hub-and-spoke” system of data access and management. Centralized ledgers have historically had many benefits, such as minimized data redundancy, limited number of access points to the data for security purposes, centralized administration, and centralized end user access. However, there are also disadvantages, such as greater potential for loss or inaccessibility if the central location suffers a hardware failure or connectivity outage, inability to recover lost data elements, and a dependence on network connectivity to allow access to the ledger by its users.

The New – Distributed Ledgers

Distributed ledgers seek to address these disadvantages by distributing (mirroring) the ledger contents to a network of participants (aka “nodes”) through a software programso that each participant has a complete and identical copy of the ledger, and ensuring all nodes agree on changes to the distributed ledger. Nodes can be individuals, sites, companies/institutions, geographical areas, etc. There is no centralized administrator or “primary node” — if a change is made to one copy of the ledger, that change is automatically propagated to all copies of the ledger in the system based on the rules of the system (called a “consensus algorithm“) which ensures that each distributed copy of the ledger is identical. For example, in Bitcoin, each node uses an algorithm that gives a score to each version of the database, and if a node receives a higher scoring version of the ledger, it adopts the higher scoring version and automatically transmits it to other nodes. Since the distributed ledger software on each node validates each addition to the distributed ledger, it’s extremely difficult to introduce a fraudulent transaction (to put it another way, transactions are audited in real time). Essentially, each node builds an identical version of the distributed ledger using the information it receives from other nodes. The use of distributed models in computing goes back to the origins of the Internet itself — ARPANET, which evolved into what we know today as the Internet, used a distributed model instead of a linear model to manage the transfer of data packets between computer networks.

The software on each node uses cryptographic signatures to verify that it is authorized to view entries in, and make changes to, the distributed ledger. If a participant with rights to modify the ledger (e.g., a digital token giving the participant the right to record a transaction) makes an addition to the ledger using the participant’s secure keys (e.g., a record of a change in ownership of an asset or recording of a new asset), the addition to the ledger is validated by the consensus algorithm and propagated to all mirrored copies of the ledger, which helps to ensure that the distributed ledger is auditable and verifiable. A key difference between centralized and distributed ledgers is that a distributed ledger cannot be forked — if you make a copy of a centralized ledger and store it somewhere else, it will be out of sync with the original copy, whereas each copy of a distributed ledger is kept identical by the client software.

Thus, the five typical characteristics of a distributed ledger are:

  1. distributed copies among nodes via client software;
  2. cryptographic signatures, or “keys,” to allow nodes to view, or add to, the distributed ledger in an auditable and verifiable fashion;
  3. a digital token (better known as a cryptocurrency)used within many distributed ledger networks to allow participants to record ledger entries;
  4. a consensus algorithm to ensure distributed copies of the ledger match among participants without the need for a centralized administrator; and
  5. record permanency so that verified entry accepted to the ledger via the consensus algorithm becomes permanent (it can be corrected via a later addition to the ledger but never removed).

Blockchain

While most press reporting around blockchains equates blockchain with distributed ledgers, a “blockchain” is a specific type of distributed ledger. Each record of new value added to the ledger and each transaction affecting entries in the ledger (which we will collectively call a “block“) includes a timestamp and a cryptographic verification code based on a data signature or “hash” from the previous block which “chains” it to the previous block, forming a “chain of blocks,” or “blockchain,” within the nodes hosting the blockchain. Because each block is cryptographically tied to the previous block via one-way hash, the entire chain is secure – a client can verify that a block in the blockchain validates against the previous block, but it does not allow someone to trace the blockchain forward. If a block in the chain is altered, it changes the hash value and no longer matches the hash stored in later blocks, and the alteration will be rejected by the nodes on the blockchain network. In a blockchain, transactions entered into the system during a specified period of time are bundled together and added to the blockchain as a new block.

There are three primary types of blockchain networks – public, private, and permissioned.

  • Public blockchains allow anyone to participate, and therefore rely more heavily on a strong consensus algorithm to ensure the requisite level of trust between blockchain participants.
  • Private blockchainsare limited to a discrete and specified group of participants, are usually small, and may not require use of a cryptocurrency given the inherent level of trust amount private blockchain participants. Private blockchains often do not require a strong consensus algorithm.
  • Permissioned blockchainsfunction much like public blockchains, but require participants have permission to access, transact on, or create new blocks within a blockchain.

Tennessee’s recent state law on blockchain, Tn. Stat. § 47-10-201, contains a good summary definition.  It defines “blockchain technology” as “distributed ledger technology that uses a distributed, decentralized, shared and replicated ledger, which may be public or private, permissioned or permissionless, or driven by tokenized crypto currencies or tokenless.  The data on the ledger is protected with cryptography, is immutable and auditable, and provides an uncensored truth.”  Arizona’s statutory definition (which predates Tennessee’s) is almost identical, except that “crypto currencies” is replaced with “crypto economics.”

Bitcoin is an early, and famous, example of a public blockchain application. Nodes on the Bitcoin blockchain network earn new bitcoins as a reward for solving a cryptographic puzzle through computing power, or “mining.” Transactions for the purchase and sale of bitcoins are also recorded in a block in the Bitcoin blockchain – the blockchain is the public ledger of all Bitcoin transactions. In other blockchain applications, the cyrptocurrency is used as payment for blockchain transactions.

Blockchain and distributed ledger technology is not intended to fully replace existing centralized ledgers such as databases. If a number of parties using different systems need to track something electronically that changes or updates frequently, a distributed ledger may be a good solution. If those needs are not there, or if there is a continuing need to rely on paper transaction records, a centralized ledger continues to be the better choice. Companies need to ensure there is a compelling ROI and business case before implementing a blockchain development and implementation program.

Smart Contracts

An important concept in blockchain technology is the “smart contract.”  Tennessee’s blockchain law defines a smart contract as “an event-driven program, that runs on a distributed, decentralized, shared and replicated ledger and that can take custody over and instruct transfer of assets on that ledger.” Arizona’s definition is identical other than an additional reference to state.  In other words, a smart contract is a computer program encoded into a blockchain that digitally verifies, executes, and/or enforces a contract without the need for human intervention. Where a traditional contract involves risk that a party will fail to perform (e.g., a shipper delivers products but the recipient fails to make payment for the products), smart contracts are self-executing and self-verifying.  In a smart contract for the purchase of goods tracked via blockchain, the seller and buyer would program a smart contract into the blockchain.  Once the delivery record is added to the blockchain, the smart contract automatically validates the shipper’s performance, and automatically triggers payment from the buyer.  Since execution of a smart contract is part of the blockchain, it is permanent once completed. Blockchain protocols such as Ethereum have developed programming languages for smart contracts.

How Might Blockchain and Distributed Ledgers Change the World?

The impact of new technology presents at first as rapidly disruptive (positively and negatively), but often manifests organically and transparently to change the world over time.

Roy Amara, a former president of the Institute of the Future, said that people overestimate a technology’s effect in the short term and underestimate it in the long run, a statement known as “Amara’s Law.” However, I think a corollary is in order – the impact of new technology presents at first as rapidly disruptive (both positively and negatively), but often manifests organically and transparently to change the world over time at a proportional rate to the maturity of the commercially available applications, to consensus on technological standards, and to decreasing costs to implement (and increasing ROI from implementing) the technology in practical business and consumer situations. For example, RFID technology was touted early on as a “change the world” technology, and it has — but most prominently through integration of the technology organic and innovative improvements to supply chain and inventory management. Social networking is viewed by many as a “killer app” (a catalyst that accelerates the adoption of a new technology) which helped usher in the third Age of the Internet, and it has changed the world by changing how we connect with others. Both took years to become pervasive in society and industry.

Blockchain and distributed ledger networks have the potential to change the way many systems and business processes work across industries. Financial and currency transactions are a prominent emerging application of distributed ledger networks and blockchain technology. Since blockchain and distributed ledger networks are platform-agnostic, a distributed ledger could be stored in different hardware/software configurations across different nodes, reducing the need for expensive and time-consuming upgrades to support the distributed model. For example, a permissioned blockchain model could help an organization such as the US Veterans Administration better manage appointment scheduling across a large number of hospitals and clinics (in fact, a resolution was recently passed in the US House of Representatives promoting just that, “to ensure transparency and accountability.” Industry groups, such as the Blockchain in Transport Alliance (BiTA), have sprung up to help develop and promote industry-specific blockchain standards and applications.

The technology could also be used in applications such as better and more secure management of governmental records and other services; tracking tax collection and receipts; managing assets; identity verification; decentralized voting; managing and tracking inventory levels and B2B/B2C product fulfillment; tracking the “data supply chain” for the flow of data among systems; managing system access controls; protection of critical public and privacy infrastructure; tracking royalties due to artists for the use of their works; and use of smart contracts to digitally create, execute, and enforce agreements between parties via blockchain transactions. Distributed ledger networks have the advantage of being more secure as the consensus algorithm makes it considerably difficult for a cyber-attacker to successfully alter the distributed ledger. It could also allow for greater access transparency, a central tenet of many privacy principles, by allowing individuals to access records in the ledger relating to them or containing their information.

Blockchain and Distributed Ledger Legal Risks and Issues

As with any new technology, blockchain creates some interesting conflicts with existing laws and regulations and raises interesting and complex legal and compliance issues.  These include:

Data privacy issues. Distributed ledger technology such as blockchain is inherently designed to share information among every participant and node. If information in a ledger transaction or block contains private information, such as an account number or company confidential information, it will be visible to every user of every node. This is one of the reasons permissive and privacy distributed ledgers are a focus of many companies seeking to innovate in the space. Additionally, as nodes in a distributed ledger network can be geographically disparate, rules and requirements for the transfer of data between geographies may play a major role. It is also possible that at some point in the future decryption technology will evolve to the point where cryptographic signatures used in blockchain and distributed ledgers may no longer be considered safe.

EU personal data and the “Right to be Forgotten.”  In the EU, personal privacy is considered a fundamental human right under the Charter of Fundamental Rights of the European Union. The General Data Protection Regulation (GDPR) is Europe’s new comprehensive data protection framework that as of May 25, 2018 has the force of law in every EU member state.  Under Article 17 of the GDPR, EU data subjects have a “right to be forgotten” which requires companies to erase personal information about that data subject if certain conditions are met (e.g., the personal data is no longer necessary in relation to the purposes for which they were collected or otherwise processed). This right has cropped up in the United States as well, for example, in California for minors under 18 with respect to websites, social media sites, mobile apps, and other online services under Cal. Bus. & Prof. Code § 22580-81.  The “right to be forgotten” creates a direct conflict with the permanency of blockchain.  Companies should factor the “right to be forgotten” into their blockchain development planning, e.g., consider hashing technologies to pseudonymize personal data before encoding it into a blockchain, or other ways to avoid this conflict.  Developments in blockchain and distributed ledger technology may also arise to address this issue.

Jurisdictional issues.The nodes in a blockchain are often in multiple jurisdictions around the country and/or around the world.  As each is a perfect copy, this can create issues from a jurisdictional perspective.  Legal concepts such as title, contract law, regulatory requirements, etc. differ from jurisdiction to jurisdiction. Does a blockchain network need to comply with the laws of every jurisdiction in which a node is operated?  Cross-border enforcement may become an issue – will one jurisdiction seek to impose its laws on all other nodes of a blockchain network? Blockchain network operators should consider how to specify, in a binding manner, a single choice of law and venue to govern disputes arising from the blockchain network and provide specificity as to compliance requirements.  This jurisdictional issue will likely lead to races between jurisdictions to establish themselves as a “blockchain and distributed ledger friendly” jurisdiction, just as Delaware established itself as a “corporation-friendly” jurisdiction in which many corporations choose to incorporate.  Jurisdictional issues will also impact discovery of data within the digital ledger network, e.g., through subpoenas.  The rules regarding document discovery differ from state to state.  A company seeking to obtain blockchain data through judicial process may have the ability to engage in “forum shopping” to find the most convenient, and friendly, jurisdiction in which to file a document discovery request.

Record retention risks. One of the features of blockchain and distributed ledger networks is record permanency. This permanency may be incompatible with statutory requirements for data to be destroyed and deleted after a period of time, such as credit/debit card data under PCI rules and HR data under various regulatory requirements, and under privacy frameworks such as the GDPR.  It also likely conflicts with a company’s existing record retention policies.  Given these factors, companies looking to introduce blockchain technology should review their record retention policies and create a separate “permanent” category for data stored in blockchain applications.  At the same time, a blockchain is permanent so long as the blockchain itself still exists.

Service Level Agreements.  Many companies include a service level agreement (SLA) in their service agreements, which provides committed minimum service levels at which the service will perform, and often includes remedies for a breach of the SLA.  SLAs are relatively easy to offer when they are limited to a company’s own systems and infrastructure.  However, a blockchain (other than perhaps a small private blockchain) may by its very nature be distributed beyond a company’s own network.  SLAs often exclude from downtime issues outside of its control, e.g., downtime caused by a third party’s hardware or software.  Does a third-party node still fit within this? Many SLAs also address latency, i.e., the time it takes for a system to respond to an instruction. Companies will also need to think about what measure of latency (if any) should apply to transactions via blockchain and other distributed ledgers, and how to address blockchain in their SLAs.

Liability and Force Majeure issues. Companies routinely implement controls (processes and procedures) to manage their systems and operations, which controls may be audited by customers/partners or certified under standards such as SOC 2. But who is accountable for a database distributed across geographies and companies? Use of a distributed ledger system with nodes outside of a company’s systems means ceding some control to an automated process and to a decentralized group of participants in the distributed ledger/blockchain. An error in a record in a distributed ledger becomes permanent and can be corrected but never removed. Is an issue with a third-party node considered a force majeure event which excuses performance under an agreement? Is the type of network (public, private or permissioned) a factor?  Companies will need to think about how blockchain should tie into an agreement’s general force majeure provision, and how to allocate blockchain risk within a contract (through indemnities, limitation of liability, etc.).

Insurance issues.  Any new technology is quickly tested under insurance policies.  Companies will begin to tender claims under their electronic errors and omissions policies, commercial general liability policies, and possibly specialized cyber policies.  As insurance companies build up experience with blockchain claims, companies will likely see new endorsements and exclusions limiting insurance carriers’ liability under standard policies for blockchain-related losses.  This is often closely followed by the emergence of custom policy riders (for additional premium) to provide add-on insurance protection for blockchain-related losses.  Companies implementing blockchain technologies may want to discuss blockchain-related losses with their insurance carriers.

Intellectual property issues.As with any new technology, there has already been a flood of patent applications by companies “staking their claim” in the brave new frontier of blockchain and distributed ledger. While the core technology is open source, companies have created proprietary advancements in which they may assert patent or other intellectual property rights.  Dozens of companies have already obtained blockchain patents.  Technology and other financial companies have undoubtedly already filed large numbers of blockchain patents that are working their way through the Patent and Trademark Office.  As is often the case with new technologies, there will likely be a flurry of patent infringement lawsuits as new patent holders seek to enforce their exclusive rights to their inventions.  Adopters of blockchain using custom applications or non-standard implementations should be especially sensitive as to whether their application or implementation could potentially be infringing filed or issued blockchain patents.  Consulting external patent counsel knowledgeable in blockchain technology will become more and more important for these types of adopters.

Confidentiality issues. Information placed into a node of a public blockchain – even if that node is within a company’s own servers – is no different than putting code into GitHub. The result is that the information enters the public domain. Even with a private or permissioned blockchain, information encoded into the blockchain becomes visible to all participants with access rights.  A company’s use of a blockchain or distributed ledger to store confidential information, such as information subject to an NDA or the company’s own trade secrets, creates a risk of a breach of confidentiality obligations or loss of trade secret protection.  Companies should consider how to prevent confidential and other sensitive company information from being stored in blockchains in a manner that could result in a breach of confidentiality. Additionally, agreements routinely require the return or destruction of the discloser’s confidential information and other provided data and/or materials upon termination or expiration. An exception for data encoded onto a blockchain must be considered.

Discovery and Subpoenas.  Information encoded into a public blockchain may be considered in the public domain.  When litigation arises, will companies be able to push back on a discovery request encompassing data in a blockchain by stating that it is publicly available?  If a person can find the identity of other nodes in a blockchain network, we may see an increase in subpoenas directed to a node for blockchain data within the copy of the blockchain or digital ledger hosted at that node (possibly based on favorable jurisdiction as noted above). Since every node maintains their own copy of a distributed ledger, and no one node owns or controls the data, this may affect the ability of a company to keep information out of third party hands as they may not have the ability to quash a subpoena directed at an independent node.

Application of existing legal structures to blockchain, smart contracts, and distributed ledgers. As is often the case, one of the challenges for lawyers and others is determining how existing laws and regulations will likely be interpreted to fit new technologies such as blockchain and distributed ledger technology; what new laws and regulations may be coming and how permissive or restrictive they may be; and how enforcement and penalties in connection with the new technologies under both new and existing laws will play out. “Smart contracts” that rely on computer algorithms to establish the formation and performance of contracts may challenge the nature and application of traditional legal principles of contract law such as contract formation and termination, and the traditional focus of laws on the acts of persons (not automated technologies), making it difficult for courts to stretch traditional contract law principles to the new technology.

Emerging laws.  It is axiomatic that law lags technology. The companies that immediately benefit from a new disruptive business method such as blockchain are those which seek to innovate applications of the method to monetize it, obtain a first mover advantage, and ideally seize significant market share for as long as possible. Industry groups and trade associations form to seek to promote it, and legislators take notice (especially given the meteoric rise of bitcoin prices during 2017). Legislators often jump to regulate something they don’t fully understand and whose potential is not fully realized, which can impede development and proliferation of the new technology.  A handful of states (including Arizona, Nevada, Tennessee, Delaware, Illinois, Vermont, and Wyoming) have already adopted blockchain-specific legislation, and this number will likely grow substantially in the next couple of years. Fortunately, the legislation enacted to date appears to support, rather than inhibit, blockchain technology. Other states have introduced or enacted legislation to study blockchain technology.

Disruptive technologies such as blockchain and distributed ledger technology bring both benefits and potential risks. If the benefits outweigh the risks on the whole, the public interest is not served when the legal, regulatory and privacy pendulum swings too far in response. The spread of blockchain and other distributed ledger technologies and applications will be dependent on the creation and fostering of a legal, regulatory, and privacy landscape that fosters innovation in the space.

Eric Lambert is the Commercial Counsel for the Transportation and Logistics division of Trimble Inc., an integrated technology and software provider focused on transforming how work is done across multiple professions throughout the world’s largest industries. He is counsel for the Trimble Transportation Mobility (including PeopleNet, Innovative Software Engineering, and Trimble Oil and Gas Services) and Trimble Transportation Enterprise (including TMW and 10-4 Systems) business units, leading providers of software and SaaS fleet mobility, communications, and data management solutions for transportation and logistics companies. He is a corporate generalist and proactive problem-solver who specializes in transactional agreements, technology/software/cloud, privacy, marketing and practical risk management. Eric is also a life-long techie, Internet junkie and avid reader of science fiction, and dabbles in a little voice-over work. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice.

7 Tips for Implementing a Records Retention Policy Employees Will Follow

Posted on by
Reply

How long to hang on to corporate information and records (records retention) is a common source of conflict within companies. Those in the “keep it” camp believe companies should keep any business records that are needed to conduct business operations effectively, records that serve as a company’s “corporate memory,” records that must be kept for legal, accounting or other regulatory compliance purposes, or have other value to the company (such as protecting the company’s interests). Those in the “destroy it” camp believe companies must promptly destroy records when there is no longer a legitimate business need to retain them, in order (a) to ensure they are minimizing the amount of information that could potentially be exposed in the event of a security breach, inadvertent disclosure, legal disclosure requirement such as a subpoena, or during the discovery phase of litigation, (b) to comply with legal, accounting and other regulatory requirements to destroy information after a certain time, and (c) to reduce the costs of discovery and of storing corporate information. Which side is right?

The answer, of course, is that they’re both right. All of the reasons to keep corporate records, and all the reasons to destroy them, are legitimate. This is the “double-edged sword” of records retention.  For every argument that “we might need that piece of information somewhere down the line,” there’s a counterargument that “we could get in trouble someday if we still have that piece of information around.” The way to ensure your company is striking the right balance between these two extremes is to have a written records retention policy that balances the reasons to retain information against the reasons to destroy it, by setting appropriate “retention periods” for various categories of corporate records and requiring employees to destroy data once the retention period is ended in most cases. It is an essential component of a company’s incident response planning process to reducing the amount of information potentially exposable in the event of a security incident or breach. The policy must cover corporate records wherever located, including physical and electronic data wherever stored (in employee workstations, on intranets and network drives, in third party data centers, in cloud-based service providers’ systems, etc.)  It should list the categories of business records governed by the policy (I prefer a table format), and the records retention period for each category. It should clearly explain to employees what they need to do to comply with the policy, including how to ensure records are properly destroyed when the retention period ends.

It’s easy to argue why companies need a records retention policy. It’s much harder to actually draft and successfully implement one. Here are 7 drafting and implementation tips to help drive the success of your records retention policy.

1. Success is directly proportional to simplicity and communication.

The simpler you can make a records retention policy, the easier it will be for employees to follow it and the greater the likelihood that employees will take time to follow it. Policies that add significant process requirements into the life of rank-and-file employees who already feel like they are “doing more with less” and may be resistant to new ways of doing things are often met with skepticism at best, and outright rebellion at worst. It can be very difficult to successfully implement and administer a records retention policy if employees feel it is onerous and unnecessarily impeding their ability to do their job. If that happens, employees may simply ignore the policy in favor of their day-to-day business duties, or worse, use the records retention policy as a scapegoat if they fail to deliver on their projects and goals.

To solve this problem, ensure your policy is written as simply as possible, take into account the employee’s perspective, and have a communication plan to roll it out. Ensure your policy overview answers questions such as “Why is having a records retention policy important to me?”, “How hard will it be to follow the policy?”, and “What do I have to do under the policy?” Consider using a “frequently asked questions” format for the policy overview. Have a few employees whose opinion you value give you feedback on the policy. Develop a communication plan to roll out the policy to all employees, and leverage HR and Marketing for their input to make it as effective as possible. Ensure your senior leadership team endorses the policy so employees understand it has top-level visibility.

2. Set a “once per year” date for retention periods to expire.

One way to write a records retention policy is to have a fixed retention period for each business record run from the date the record was created. Under that approach, retention periods will be expiring throughout the year.  If the records retention policy requires employees to destroy records immediately upon expiration of the retention period, the policy may require employees to be managing document destruction on a daily or near-daily basis. This may make compliance seem like a daunting task to employees, even if your policy allows employees to destroy expired business records one per month or once per quarter.

As an alternative, consider having the expiration date for all retention periods expire on the same day during each calendar year by having your retention period be measured in full “retention years,” defined as a full calendar year or other 12-month measurement period. For example, if you set December 31 as your annual date for expiration of records retention periods, a presentation created on May 15, 2016 which must be kept for 3 “retention years” would be kept from May 15, 2016 through December 31, 2019 (3 full calendar years from the date of creation). While this approach does extend the retention period for some documents by a bit, that may be an acceptable trade-off to a simple, once-per-year obligation to destroy records under the records retention policy. Consider tying your annual records retention period expiration date into an “office clean-up days” event in partnership with HR where everyone pitches in to tidy up the office, clean up their workspaces, and destroy any documents for which retention periods have expired under the records retention period.

3. Right-size the departments and categories of corporate records listed in the policy.

In an effort to be as comprehensive as possible, some records retention policies include a significant number of categories of information subject to retention requirements. This can result from using an “all purpose” template such as a template obtained from a law firm, from a colleague, or from online searches. In others, a company may want to ensure they are not missing anything by including everything employees have today or could have in the future. One size does not fit all with respect to records retention categories. Consider having a “general” or “common business records” category as the first section of business records in your policy, covering items like business presentations, contracts and agreements (both current and expired); general and customer/vendor correspondence; material of historic value; software source code; etc. Then determine which departments have additional, specialized categories of business records (e.g., HR, IT, Finance, Marketing, Legal, etc.) that should be listed specifically in the policy. For each such department, learn which business records they have and use to create a first draft of your categories list and retention periods. Using a general/departments grouping of categories allows employees to find the information on records retention applicable to them a targeted and streamlined fashion. There will likely still be a significant number of categories of corporate records, but taking the time to think through the right categories for your company’s records retention policy will help ensure it is as easy as possible for employees to read, follow and use.

4. Use a limited number of retention periods, with “permanent” used as sparingly as possible.

Another common issue with records retention policies is the use of a large number of retention periods. Different departments may have different periods under which they currently retain documents, and they may put pressure to keep their own retention periods in an enterprise-wide policy. A policy with a large number of retention periods will make it harder for employees to follow, and harder for IT and others to operationalize. Remember, simplicity where possible is key to success. Consider using a limited number of retention periods (e.g., 1 year, 3 years, 5 years, 7 years, Permanent) which will simplify administration of, and compliance with, the policy. For departments with different existing retention periods, determine which of the next closest periods (longer or shorter) will work, and be prepared to explain to the head of that department why a limited number of periods is essential to the successful implementation of an enterprise-wide policy.

It can be tempting to put many things into a “permanent” bucket (those in the “keep it” camp are likely candidates to ask for this category). However, overuse of the “perpetual” category cuts against the reason for implementing the policy in the first place. While some documents may need to be kept perpetually, for example, information subject to a document preservation notice due to litigation, document categories should be assigned a “permanent” retention period very sparingly. Use it where it is legally necessaryto preserve a category of documents (e.g., it’s required for regulatory purposes), or where there is a compelling business interestin keeping it forever (e.g., prior art that may have value in defending against a future patent infringement claim). One way to find a “happy medium” with those in the “keep it” camp is to include in your policy a mechanism by which Legal and the CISO/CIO can approve an exception to the retention period on a case-by-case basis, but make clear that exceptions will be rarely very sparingly and only where legally necessary or where there is a compelling business interest.

5. Partner with department heads to solicit and incorporate their feedback, and to turn them into champions of an enterprise-wide policy.

One of the keys to the successful roll-out of a records retention policy is to have the support of senior management and department heads. Compliance with a records retention policy should be driven from the top down, not bottom up. It’s also important to consider that just because a company has not implemented an enterprise-wide records retention policy does not mean that some departments have not “gone it alone” and implemented their own limited retention and destruction schedule. Partnering with department heads to gain their support for an enterprise policy, and ensure their own efforts are leveraged as part of the broader policy, is essential.

Once a draft policy is prepared, set up one-on-one meetings with the leader of each department to let them know that you want the enterprise policy to be a collaborative (and not an imposed) effort on his/her department. If they have department-specific document categories or retention periods, leverage them to the greatest extent possible to minimize the impact the enterprise policy will have on that department. If they do not, walk them through the reasons why having a well-followed enterprise records retention policy will benefit the company as a whole. Walk the department head through the draft policy, and ensure they agree with the categories and retention periods applicable to their business unit. Try to incorporate their feedback wherever possible, and talk them through where you cannot (e.g., they ask for a non-standard retention period). Finally, ask for their help in rolling the policy out to their department, e.g., by sending a note to the department as a follow-up to the enterprise-wide policy announcement. By meeting with department heads, you will not only ensure the policy hews as closely as possible to the operational and compliance needs and practices of each department, but also establish a contact for future revisions/enhancements to the policy, and hopefully foster an internal champion to help drive the success of the policy.

6. Ensure the policy accounts for document preservation notices.

One critical element of any records retention policy is a very important exception — information subject to a litigation hold or other document preservation notice (such as in the event of litigation or anticipation of future litigation, where the company receives a subpoena, etc.) If employees follow the records retention policy and destroy business records that are relevant to a legal proceeding or subpoena, the company could face very significant fines and penalties. Ensure that the records retention policy makes it very clear that a document preservation notice supersedes the records retention periods, and that any documents and business records subject to a litigation hold or other document preservation notice must be kept for as long as the preservation notice is in effect regardless of the expiration of the retention period. It’s also important to communicate that once an employee is notified that a document preservation notice has been canceled, any documents subject to the notice should be destroyed at the next anniversary date. Ensure that any systems and processes used by the company to operationalize the records retention policy (e.g., automatic deletion of emails after a certain amount of time) account for the preservation of documents and business records subject to a preservation notice irrespective of the retention periods.

7. Partner with IT to implement technical safeguards to minimize policy “workarounds.”

Finally, partnering with IT will be critical to the success of the policy. In many cases, some document destruction processes can be automated (for example, emails can be deleted after a certain period, files older than a certain date can be automatically deleted from network shares, etc.) Work with your IT group to determine what technological solutions can be put in place to help operationalize the records retention policy. At the same time, some employees may believe that their needs trump the records preservation policy, and will try to work around it (e.g., by saving emails to a PST, printing them to a PDF and saving them on a network drive, “backdating” them by changing the system date before saving files, etc.) Partner with your IT team to put as many appropriate technical safeguards in place as possible to minimize employee workarounds to the records retention policy.

Eric Lambert is Assistant General Counsel and Privacy Officer at CommerceHub, a leading cloud services provider helping retailers and brands increase sales and delight shoppers by expanding product assortment, promoting and selling products on the channels that perform, and enabling rapid, on-time customer delivery. He works primarily from his home office outside of Minneapolis, Minnesota. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice. He is a technophile and Internet evangelist/enthusiast. In his spare time Eric dabbles invoice-over work and implementing and integrating connected home technologies.

Why Accessible Websites and Mobile Applications Matter

Posted on by
Reply

The Internet is an essential part of life in the 21st century. A 2015 Nielsen study found that people spend an average of 2.5 hours a day using smartphones and PCs to access the Internet.

Look at any website or app and think of how different the experience would be if you couldn’t see it or hear it like everyone else.  The American with Disabilities Act (“ADA”) was enacted in 1990 to ensure Americans with disabilities had equal access to places and things such as government facilities and places of public accommodation.  Soon after the ADA was enacted, a new communications medium arose – the World Wide Web, marking the start of the Second Age of the Internet.  The question soon arose as to what extent websites were “places of public accommodation” requiring reasonable accommodations to allow use by disabled Americans under the ADA.  The Department of Justice has repeatedly delayed its rulemaking on website accessibility guidelines, most recently postponing it to at least 2017.  This may be due to the explosion of apps on the Internet and the corresponding decrease in website usage – a recognition that the landscape of what would be regulated is changing too rapidly at this point.

However, don’t think you’re safe to just wait for the DOJ’s guidance. Even without rules, the DOJ has gone on record stating that the ADA applies to web services. The DOJ has instituted a number of lawsuits against companies which they believe are not meeting accessibility standards, including their websites and apps.  For example, in 2015 the DOJ settled with Carnival Cruise Lines requiring not only improvements in accessibility of its ships, but of its website and mobile application.  Many US companies are unaware that under Section 508 of the United States Workforce Rehabilitation Act of 1973, websites and apps developed by companies receiving federal funds or under contract with a federal agency must meet certain accessibility standards.  Private and government litigants continue to bring actions against companies under federal and state law for inaccessible websites – over 45 in 2015 alone, according to BNA.  There have reportedly been many more demand letters sent to companies concerning digital properties allegedly inaccessible by persons with disabilities.

Despite the uncertain landscape, there is a path forward to minimize the risk that your company’s digital properties will come under scrutiny or attack. All companies, and especially those currently or prospectively doing business with the government, should make accessibility part of the calculus when designing, building, and refreshing websites and mobile applications. Here are some important considerations for companies.

(1) Ensure your web and app developers are familiar with WCAG 2.0 standards and Section 508 requirements. Although the DOJ has not yet released its own rules, they continue to use Version 2.0 of the Web Content Accessibility Guidelines (WCAG 2.0) as a de facto standard.  WCAG 2.0 was released in 2008 and became an ISO standard in 2012. There are 4 core principles for web content under the guidelines:  content must be Perceivable (e.g., alternatives for non-text content, alternative content presentation, separate foreground and background content, etc.); Operable (e.g., make all functionality keyboard-accessible, allow sufficient time to read content, ensure navigation and search are easily usable, etc.); Understandable (e.g., clear text content, predictable operation of web pages, etc.); and Robust (e.g., use standardized and proper tagging; ensure content can be interpreted reliably by varied user agents such as assistive technologies).  While there are 3 levels of conformance with WCAG – A, AA, and AAA – AA is the most common and the one referenced in most litigation and DOJ actions.  Additionally, Section 508 imposes specific obligations on software applications and operating systems and intranet and Internet websites.

It’s very likely a future version of WCAG will form a foundation of the DOJ’s guidance; the DOJ has referred to the WCAG as a recognized international industry web accessibility standard. If the DOJ’s advice aligns with this standard, it will likely mean only minor accessibility adjustments will be required by companies that are already WCAG compliant. If you have international users of your digital properties and/or an international presence, consider whether international standards such as Canada’s Standard on Web Accessibility, the UK’s Disability Discrimination Act, and France’s AccessiWeb impose any obligations above and beyond WCAG 2.0 AA.

(2) Ensure your app developers are also familiar with and OS assistive capabilities such as Google Talkback and VoiceOver for iOS.  Google and iOS both have assistive software.  Apple offers VoiceOver, a gesture-based screen reader integrated with iOS.  Google Talkback similarly enhances Android with spoken, audible and vibration feedback to better enable use of Android devices by visually impaired persons.  Your app developers should understand these and other assistive technologies available for app operating systems so they can utilize them to the fullest extent possible.

(3) Perform an accessibility audit of your digital properties. An accessibility audit will help you understand what accessibility improvements are needed to ensure WCAG 2.0 AA and Section 508 compliance, as well as the cost and resources that will be required for your company to achieve compliance.  Being able to demonstrate the costs of compliance vs. some of the settlements forced by litigants and the DOJ can help add a quantifiable metric to the risk analysis. An internal audit can be helpful to ensure your internal team understands the accessibility requirements, but also consider using third party tools and partners such as SiteImprove, IBM’s Rational Policy Tester Accessibility Edition, ACCVerify, or ComplianceSherriff.

(4) Make “accessibility by design” part of your creative development process. Many of the visual design elements we take for granted, such as layouts, have a very different meaning (if any) to a visually disabled person. Audiovisual content is very different to a hearing-impaired individual – if can be very difficult for a captioned video to deliver the nuances of inflection that often go into a vocal performance.  Consider the user experience of someone hearing your copy (not just reading it), or reading your video or narration (not just hearing it).  Consider having your marketing and design teams use screen readers and watch captioned videos for a better understanding of that experience with their content. Include audio captions in videos or narrated presentations to assist hearing-impaired individuals. Look at what features and functionality are available to assist you with enabling accessible creative content.

(5) Make it part of your coding and testing DNA, too. Ensure your web design techniques promote accessibility. Make the WCAG 2.0 AA guidelines, Section 508 requirements, and OS assistive capability support part of your development requirements for any new coding project or project refresh.  When contracting with web and app developers and with web and commerce platform vendors, ask them for examples of projects they’ve done which were assistive technology and guideline compliant, and require them to follow accessibility guidelines. Use web design tools that support and enable accessibility.  When you develop customer profiles for testing, consider adding profiles for visually-impaired and hearing-impaired users.

Website and app accessibility compliance can seem daunting, but it doesn’t have to be. Knowing accessibility requirements and guidelines, and your company’s current implementation of them in their digital properties, is an important first step.  Making a plan to build accessibility into your company’s design and development DNA, and implementing accessibility support and features in your digital properties, can help keep you ahead of both accessibility litigation and future government regulations.

Litigation Management for the In-House Generalist and Business Leader (Part 6)

Posted on by
Reply

Understanding the basics of litigation management is essential for in-house counsel, and can give business leaders more perspective on playing the “litigation card.” Recently InsideCounsel Magazine published the last in a six-part article series entitled “Litigation Management for the In-House Generalist” co-authored by myself and Michael Geibelson, a partner at Robins Kaplan LLP and a top-notch litigator.  Part 6 in the series provides twelve discovery best practices to keep in mind, and closing thoughts. Click here to read the article. I hope you have enjoyed this article series!

Litigation Management for the In-House Generalist and Business Leader (Part 5)

Posted on by
Reply

Understanding the basics of litigation management is essential for in-house counsel, and can give business leaders more perspective on playing the “litigation card.” Recently InsideCounsel Magazine published the fifth in a six-part article series entitled “Litigation Management for the In-House Generalist” co-authored by myself and Michael Geibelson, a partner at Robins Kaplan LLP and a top-notch litigator.  Part 5 in the series discusses discovery and the core discovery types – written, oral, and visual. Both in-house counsel and business leaders can benefit from having an understanding of what discovery entails as it is the aspect of litigation that intrudes the most into a company’s day to day business operations.  Click here to read the article, and enjoy.

The Pros, Cons, Do’s and Don’ts of Competitor Keyword Bidding

Posted on by
Reply

Companies regularly bid on their own keywords, and generic terms related to their business, as part of their overall paid search strategy.  Bidding on competitors’ keywords (company name, brand names, product names, etc.) in paid search advertising is also a common practice. Google has allowed companies to bid on third party trademarked terms since 2008.  Plaintiffs have had an increasingly difficult time in recent years winning trademark infringement cases involving competitor keyword bidding.  Many companies appear to have adopted an “if you can’t beat ’em, join ’em” approach.  So should your company be bidding on competitors’ keywords too?

The answer, as is often the case, is, “maybe.”  There are many pros and cons to bidding on competitors’ keywords, and do’s and don’ts, to keep in mind.

  • PRO:  Bidding on competitors’ keywords targets your company’s market and promotes brand awareness.  Companies can use competitor keyword bidding to advertise to persons looking for similar products and services, helping to ensure your products are reaching the broadest possible market.
  • PRO:  Bidding on competitors’ keywords presents alternatives in the marketplace. Competitor keyword bidding helps ensure your company’s name and brand is presented as an alternative to someone searching for a competitor’s products.  This provides consumers with choices on available products and levels the playing field (especially when your competitors are bigger than you).
  • PRO:  Bidding on competitors’ keywords is often less competitive.  Competitors’ keywords are generally less competitive than generic terms, as fewer companies bid on them.
  • CON:  Bidding on competitors’ keywords could trigger a bidding war.  If your competitor isn’t already bidding on your company’s keywords, it may take an “eye for an eye” approach and start bidding on your company’s keywords, driving up your own paid search listing fees.
  • CON:  Competitors’ keywords generally result in a low click-through rate, which can have consequences.  The click-through rate (CTR) for listings triggerest by a competitor keyword can be low.  For Google, failing to achieve a strong CTR on an ad campaign can affect your company’s AdWords Quality Score (QS), driving up the company’s overall Cost Per Click (CPC) for paid search listings.
  • CON:  While litigation over competitor keyword bidding is unusual these days, it’s not unheard of if you don’t carefully follow the rules.

If you decide that the pros outweigh the cons and want to dive (or wade) into competitor keyword bidding, here are some Do’s and Don’ts to consider:

DOdifferentiate your company in the ad creative by including a clear offer or unique selling point to draw potential customers away from the company they were looking for.  Find a way to differentiate yourself and present a value proposition in your ad to get a potential competitor customer to look at you instead.

DOalways mention your company’s name advertisements served via competitor keyword bidding.

DOcheck competitors’ keywords for alternate meanings (e.g., through Google Suggest and Google Search).  Other meanings could mean serving ads to persons searching for an alternate meaning, resulting in a low CTR.

DON’T use dynamic keyword insertion for a campaign involving a competitor’s keywords.  Not only is it a violation of Google’s AdWords policy, it can potentially expose you to trademark infringement claims.

DON’T mention a competitor’s name in your own ad copy served through competitor keyword bidding, or use it in a way that could cause a consumer to think you’re somehow associated with or sponsored by your competitor.

DON’Tbe deceptive, confusing or misleading, or make unsubstantiated claims, in your advertising creative or design (it’s never a good idea to try to trick someone into clicking on your ad).

Finally, DON’T try to outbid your competitors for their keywords.  Try to be #2 or #3 on the search results page to avoid a higher bounce rate and Quality Score impact.  Avoid starting a keyword bidding war — there’s never a winner, and the 1982 movie WarGames said it best (“the only winning move is not to play.”)

Litigation Management for the In-House Generalist and Business Leader (Part 4)

Posted on by
Reply

Understanding the basics of litigation management is essential for in-house counsel, and can give business leaders more perspective on playing the “litigation card.” Recently InsideCounsel Magazine published the fourth in a six-part article series entitled “Litigation Management for the In-House Generalist” co-authored by myself and Michael Geibelson, a partner at Robins Kaplan LLP and a top-notch litigator.  Part 4 in the series discusses retaining outside counsel, and the role in-house counsel needs to play in litigation.  Click here to read the article, and enjoy.

 

Litigation Management for the In-House Generalist and Business Leader (Part 3)

Posted on by
Reply

Understanding the basics of litigation management is essential for in-house counsel, and can give business leaders more perspective on playing the “litigation card.” Recently InsideCounsel Magazine published the third in a six-part article series entitled “Litigation Management for the In-House Generalist” co-authored by myself and Michael Geibelson, a partner at Robins Kaplan LLP and a top-notch litigator.  Part 3 in the series looks three more important areas of focus early in the litigation cycle – insurance, indemnification, and litigation holds.  Click here to read the article, and enjoy.

Litigation Management for the In-House Generalist and Business Leader (Part 2)

Posted on by
Reply

Understanding the basics of litigation management is essential for in-house counsel, and can give business leaders more perspective on playing the “litigation card.” Recently InsideCounsel Magazine published the second in a six-part article series entitled “Litigation Management for the In-House Generalist” co-authored by myself and Michael Geibelson, a partner at Robins Kaplan LLP and a top-notch litigator.  Part 2 in the series looks at nine actions you can take when you receive a complaint which will pay dividends later in the litigation process.  Click here to read the article, and enjoy.

Litigation Management for the In-House Generalist and Business Leader (Part 1)

Posted on by
Reply

Understanding the basics of litigation management is essential for in-house counsel, and can give business leaders more perspective on playing the “litigation card.”  Yesterday InsideCounsel Magazine published the first in a six-part article series entitled “Litigation Management for the In-House Generalist” co-authored by myself and Michael Geibelson, a partner at Robins Kaplan LLP and a top-notch litigator.  Part 1 in the series introduces the six phases of litigation and provides important information on what to consider when commencing litigation.  Click the link above (or click here) to read the article, and enjoy!