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

Posted onApril 7, 2018 by admin

[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 program�so 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:

distributed copies among nodes via client software;
cryptographic signatures, or “keys,” to allow nodes to view, or add to, the distributed ledger in an auditable and verifiable fashion;
a digital token (better known as a cryptocurrency)used within many distributed ledger networks to allow participants to record ledger entries;
a consensus algorithm to ensure distributed copies of the ledger match among participants without the need for a centralized administrator; and
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.

Paralegal vs. Legal Assistant vs. Junior Attorney – Know the Differences and Pick the Right Professional Before Hiring or Contracting

Posted onJanuary 8, 2018 by admin

It’s a good sign when the volume of legal work at a company increases to the point where another legal resource is needed, either permanently or temporarily. Most often a company will look for a generalist resource, such as a paralegal, a legal assistant, or a junior attorney, to handle a variety of tasks and free up time for senior attorneys and other specialists to focus on other work. However, many companies post a new position or reach out to a placement firm for a temporary resource without first thinking through which type of legal professional is best suited for the needs of the organization.

Paralegals and legal assistants are non-attorney legal professionals that can perform substantive legal work under the supervision of an attorney, and often form an integral part of an in-house legal department or law firm. There are advantages and disadvantages to adding a paralegal, legal assistant, or junior attorney. Thinking through whether a paralegal, legal assistant, or junior attorney is the best role for your company’s needs can help maximize productivity for the person filling the role, and help ensure that the person is capable and ready for the work he or she will be tasked to perform. Just as important, understanding what attorney and non-attorney legal professionals can’t do, and how they should be classified from an employee perspective, can help protect your company (and any existing in-house attorneys) from ethical or business issues.

I’ll conclude with a note about contract managers, another role used by some companies to manage transactional work.

Differences at a Glance

At a high level, here are the differences between paralegals, legal assistants and junior attorneys:

Diving In

Let’s look at each of these roles in a little more detail.

Paralegals

Paralegals are non-attorney legal professionals with education, a certification, work experience, or other training which allows them to perform substantive legal work under an attorney’s guidance and supervision. Paralegal as a profession first appeared in the 1960s. Paralegals support the substantive work of attorneys by allowing attorneys to delegate work to them that attorneys would otherwise need to perform directly. Paralegals can play a critical role within legal departments given the breadth of work they can perform. Unless it involves the unauthorized practice of law (which I’ll address later in the article), paralegals can be delegated almost any project that an attorney would normally perform, as long as the paralegal is qualified to do it or willing to learn and the paralegal is supervised by an attorney. Paralegals at smaller departments may also handle administrative tasks for the legal team. There are a number of certification programs for paralegals, such as the National Federation of Paralegal Association (NFPA)’s Paralegal CORE Competency Exam (PCCE) and Paralegal Advanced Competency Exam (PACE) and the National Association of Legal Assistants (NALA)’s Certified Paralegal (CP) and Advanced Paralegal Certification (APC) credentials. There are also paralegal associate degree, bachelor degree, and master’s degree programs.

If a company needs a legal professional with the training, experience and ability to perform substantive legal work under the supervision of one of the company’s attorneys, and does not need an attorney for the role to provide legal advice/counsel or to represent the company, a paralegal may be a good option. For example, a paralegal may be best suited to help with a document review project, to draft and negotiate standard agreements, or to research a specific question or new law.

Legal Assistants

Legal assistants also perform substantive legal work under an attorney’s guidance and supervision. Legal assistants may be tasked with administrative activities such as filing, maintaining the legal calendar of important deadlines (e.g., trademark renewal deadlines), and managing legal department bills and expense reporting. Legal assistants may aspire to grow into a paralegal role. If a company needs a non-attorney legal professional who does not possess the training, education and experience of a paralegal but who has the ability to perform both substantive and administrative legal work under the supervision of an attorney, a legal assistant may be a good option. For example, a legal assistant may be best suited to help a small legal department which has administrative needs as well as other substantive work.

Many non-attorney legal professionals within corporations prefer the title “Paralegal” to “Legal Assistant,” as it is often perceived as a more professional and senior position than that of a legal assistant. Some in-house legal departments will use the title “Junior Paralegal” for a legal assistant who does not yet have the necessary experience, education, certification or training to be a full paralegal, but where the person or the company wants the individual contributor to have a paralegal title.

Paralegals and Legal Assistants as Non-Exempt Personnel

One very important note for US employers – the US Department of Labor (DOL) has stated that paralegals and legal assistants should be classified as non-exempt personnel in most circumstances. Under 29 CFR Part 541.301(e)(7), the Department of Labor stated that “paralegals and legal assistants generally do not qualify as exempt learned professionals because an advanced specialized academic degree is not a standard prerequisite for entry into the field.” The DOL has issued opinion letters, such as FLSA2005-54 and FLSA2006-27, supporting this position. However, do not interpret this as meaning that paralegals and legal assistants are not professionals – they are (just not from a Fair Labor Standards Act perspective according to the DOL). It’s also important to note that the DOJ’s webpage on the Overtime Final Rule added a note in January 2018 stating that the DOL is “undertaking rulemaking” to revise the Overtime Final Rule, so employers with paralegals and legal professionals should watch this carefully.

Why Paralegals and Legal Assistants are Different

Many view paralegals and legal assistants as interchangeable titles and roles. For example, the American Bar Association uses the same definition for both paralegals and legal assistants. Both paralegals and legal assistants can perform substantive legal work under an attorney’s supervision. However, I think it’s more accurate to view them as two different points on the spectrum of non-attorney legal professionals. Here are some of the key differences I see between the roles:

Paralegals often perform (and expect to be tasked with) more and higher-level substantive work than legal assistants.
Legal assistants are more likely to be tasked with administrative legal responsibilities than paralegals in the same department.
Paralegals are more likely to have completed a certification, education, or other training programs demonstrating a higher level of skill and experience to provide supporting substantive legal work, and are required to maintain paralegal certifications through continuing paralegal education.
Paralegals, especially those with a certification, tend to expect a higher compensation rate/salary than non-certified paralegals or legal assistants.

What Paralegals and Legal Assistants Can’t Do

Paralegals and legal assistants can do many things, but cannot provide legal advice or opinions, sign documents or pleadings, engage in other prohibited tasks such as establishing attorney-client relationships, or engage in the unauthorized practice of law. This is a critically important point – paralegals cannot, and should not be permitted to, perform substantive legal work except under an attorney’s supervision, and should not do anything (directly or indirectly) that could be considered the unauthorized practice of law. For in-house paralegals, this can be very tricky as others will undoubtedly come to the paralegal asking for an opinion or advice. Rank-and-file employees often feel anyone in Legal should be able to give them an answer on a legal question. It’s up to the paralegal to let them know that they need to defer to the attorney on legal advice or opinions, and to ensure their work is being supervised by an attorney. The voluntary codes of paralegal ethics, such as the NALA Code of Ethics and Professional Responsibility and the NFPA Model Code of Ethics and Professional Responsibility and Guidelines for Enforcement, clearly state that paralegals cannot engage in the unauthorized practice of law, perform duties that only attorneys can perform, or take actions that only an attorney can take.

In Minnesota, like most US states, the unauthorized practice of law is illegal. Minn. Stat. § 481.02 prohibits a non-attorney from acting as an attorney or giving legal advice or services. In many states, the unauthorized practice of law is a felony. An attorney responsible for supervising the work of a paralegal or legal assistant who engages in the unauthorized practice of law will also find themselves in violation of Rule 5.5 of the Minnesota Rules of Professional Conduct which prohibits attorneys from assisting others from the unauthorized practice of law.

This is one of the reasons why the first in-house legal hire at most companies is an attorney. It is generally not recommended that a company’s first legal hire be a paralegal or legal assistant, as many of the substantive legal tasks to be performed by the first legal hire at a company require legal supervision, and outside counsel may not be willing to supervise the work of a non-attorney employed by the corporation due to ethical concerns. An attorney who fails to properly supervise the work of non-attorney legal professionals reporting to that attorney is putting his or her legal reputation, license to practice law, and company at risk.

Junior Attorneys

As licensed attorneys, junior attorneys offer a company the ability to do more than paralegals or legal assistants. Not only can they perform substantive work, but they can provide legal advice and opinions, represent the company in court, and otherwise engage in the practice of law. However, junior attorneys are usually considerably more expensive than either paralegals or legal assistants. If a company is hiring its first legal professional and does not need a more senior attorney as its first attorney (e.g., the company has a strong relationship with outside counsel that is acting in a quasi-General Counsel capacity), or needs a legal professional who can perform substantive legal work, provide legal advice and counsel and represent the company, and the company can afford the higher compensation an attorney typically requires, a junior attorney may be a good option.

Contract Managers

There is one other role used by some companies with respect to contracts – the contract manager. A contract manager is a person who is tasked with negotiating, administering and interpreting a company’s contracts (both standard and non-standard). Contract managers can be non-attorneys, or non-practicing attorneys. Contract managers often act in a project manager role to help ensure a company is meeting its requirements with respect to deliverables and other contractual obligations under its agreements. Like paralegals, there are professional associations governing contract managers, including the International Association for Contract & Commercial Management (IACCM) and the National Contract Management Association (NCMA), as well as contract manager certification programs including the NCMA’s Certified Federal Contract Manager (CFCM), Certified Commercial Contract Manager (CCCM), and Certified Professional Contract Manager (CPCM) designations which require a certain amount of continuing education. In some cases, a company’s procurement department will have contract managers who negotiate procurement and other agreements to take load off of the company’s legal team. Some companies choose to establish an in-house legal function by hiring a contract manager as their first legal professional.

Like other non-attorneys in the United States, contract managers cannot provide legal advice or opinions. However, it is an unsettled question whether a contract manager who does not have a legal degree and negotiates agreements, including risk management terms, on behalf of a company without attorney supervision is engaging in the unauthorized practice of law. Companies should consider whether to ensure contract managers are part of the Legal department and are supervised by attorneys just as paralegals must be, or alternatively require candidates for a contract manager position to hold a JD degree – the attorney would be acting not as an attorney for the corporation but in a “quasi-legal” role, and would remain subject to the Model Rules of Professional Responsibility governing attorneys, which would help avoid issues regarding the unauthorized practice of law.

Eric Lambert has spent most of his legal career working in-house as a proactive problem-solver and business partner. He is a corporate generalist who specializes in transactional agreements, technology/software/e-commerce, privacy, marketing and practical risk management. 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 in voice-over work and implementing and integrating connected home technologies.

Know and Use All the Risk Reduction Tools in Your Risk Management Toolkit

Posted onApril 18, 2017 by admin

A central tenet of risk management is that managing the legal and business risk of a particular business opportunity or course of action involves (1) reducing risks by shifting and mitigating them as much as possible, and then (2) having an authorized decision-maker “call the ball” on whether the benefits from the opportunity or course of action outweigh the remaining risks (risk acceptance), or vice versa (risk rejection). Each company has its own tolerance for risk, and its risk tolerance evolves over time — for example, a start-up is generally more willing to take risk to land business than a mature company. A company may also have different risk tolerances for different divisions or product lines. Reducing risk to within the applicable risk tolerance can make the difference on whether the business decision-maker will accept or reject the risks from your proposed opportunity or course of action. Therefore, attorneys and business owners should use every tool in their toolkit to mitigate and shift as much risk as possible before asking the business decision-maker for approval on a certain opportunity or course of action. But all too often, risk decisions are presented to the decision-maker before risk reduction strategies are fully implemented or leveraged. Why is this?

One reason for this is the mistaken belief that reducing risk is too time-consuming, and if a quick risk management decision is needed there is no time for anything more than cursory risk reduction. However, many risk reduction strategies can be implemented quickly and in parallel, or even proactively, to minimize the time impact of risk reduction. You can also pick and choose those risk reduction strategies which “move the risk needle” the most to ensure the time you are devoting to risk reduction will generate the strongest return before a risk decision is needed. Another reason for this is a failure to know and understand all of the risk reduction tools that may be available. The less residual risk a business risk decision-maker is asked to accept, the more likely the answer will be that the potential benefits to the business outweighs the risks. Given this, it’s essential to know all of the available risk reduction tools in your toolkit.

When working with a client, supplier, vendor or business partner, one of the best risk reduction strategies is to build a strong and effective working relationship. If an issue or potential risk exposure arises, the ability to leverage your relationship to work quickly and effectively to resolve the issue, and lessen or eliminate its impact to you and your company, will pay huge dividends.

Here are 10 additional risk reduction strategies to equip your risk management toolkit:

1. Separate factual risks from perceived risks with good research and information.

Risks can be generally grouped into two categories — perceived risks and factual risks. Once the facts related to a particular risk are known, a perceived risk from an opportunity or course of action may turn out not to be a risk at all. For example, a perceived risk of doing business with a particular vendor may be the potential impact to your Payment Card Industry Data Security Standard (PCI DSS) compliance. If the facts show that the vendor will not handle any PCI data, or is already PCI compliant, the risk may not play into the risk acceptance decision. Investigate each business opportunity or course of action thoroughly to ensure you are shifting and mitigating factual risks, not perceived risks. Investigate your prospective client or partner thoroughly and as early as possible. Look at publicly available information regarding the prospective partner to better understand the risks of doing business with the business partner, including its current website and former versions, its BBB rating, its capitalization and liquidity, its litigation history through PACER and other online search tools, and (if public) its security filings. Investigate whether there is a potential for disputes or litigation around a particular business opportunity (e.g., if the technology you are seeking to acquire has been the subject of intellectual property litigation). Check business references and ask what they view as the biggest risks of doing business with that vendor.

2. Shift risk through indemnification.

One of the most common ways to shift risk is through indemnification. An indemnity is a contractual provision through which one party (the “indemnifying party”) agrees to be responsible for certain monetary costs and expenses incurred by the other party (the “indemnified party”) which arise from, result from or relate to certain acts or omissions of the indemnifying party or other indemnified acts. A party will generally indemnify, defend and hold the indemnified party harmless in connection with indemnified losses and claims. Consider whether to include an indemnity obligation for breaches of representations, warranties and covenants, breach of material obligations, breach of confidentiality/security, misappropriation or infringement of IP, and other risks your company may suffer, which will shift risk and cost to the other party if paired with the right limitation of liability and other risk allocation terms. Consider whether to use a third-party indemnity (insulation from damages and losses resulting from lawsuits and other causes of action by a third party against the indemnified party), or a first-party indemnity (insulation from damages and losses suffered directly by the indemnified party, which is essentially insurance and is often hard to get). Remember that an indemnity is only as good as the company standing behind it (this ties into parental guarantees and insurance requirements, below).

3. Shift risk through insurance requirements.

Another way to shift risk to a client, vendor or business partner is to require them to maintain certain levels of insurance during the term of the relationship (and for a period of time thereafter). This can help ensure that the other party will have the resources necessary to pay you in the event their performance (or lack thereof) under your agreement with them creates a liability on the part of your company. Ensure you are requiring the appropriate types of coverage to protect against the risks you may face under the agreement (e.g., not just a commercial general liability policy, but an errors & omissions policy, cyber liability policy, etc. Consider insisting on being added as an additional insured, and ensuring that the insurance is primary and non-contributory. Consider whether to ensure it covers ongoing and completed operations, and waives the right of subrogation against you (so the insurer cannot “step into the shoes” of the insured party by paying the claim, giving them a claim against you) and the “insured vs. insured” exclusion (so a claim by you, an additional insured, against the named insured under the policy is not excluded from coverage). Strongly consider requiring a certificate of insurance for your records evidencing the coverage.

4. Shift risk by limiting contractual liability.

Another tool for shifting risk is to set a contractual risk allocation (disclaimer of certain damages and limitation of liability for direct damages) beyond which the other party is liable. For example, consider warranty disclaimers and disclaimers of liability from certain types of behaviors, e.g., a party may disclaim any liability resulting from force majeure events and/or disclaim all warranties, express or implied, not expressly set forth in the agreement. Include an appropriate disclaimer of consequential damages and the like, and limit your direct damages (but also consider whether exceptions to the general disclaimers and limits are appropriate – consider a “second tier” of liability for direct damages of a certain type, or exclusions from the limitation of liability). Consider a liquidated damages provision for certain issues that may arise. Ensure you understand what cannot be limited under applicable law (e.g., in certain states, it’s against public policy for a party to disclaim liability for its own gross negligence or willful misconduct).

5. Shift risk by using subcontractors.

Another risk shifting approach is to utilize subcontractors for certain responsibilities where the risk associated with performing the responsibilities in-house are greater than the risk your company is willing to take. For example, suppose you are refurbishing an office which will need a considerable amount of work to bring the electrical system up to code. Instead of using your own electrician, you may choose to outsource the electrical work to a more experienced subcontractor to whom you can contractually shift the risk from performance. The risk allocation and indemnity provisions in your subcontractor agreement will be critical here. While in some cases the primary contractor may remain liable in the event of a problem causing damage or liability to a third party, the risk-shifting terms in your independent contractor agreement may help protect your company.

6. Shift risk through a parental guaranty.

If the potential counterparty or business partner is not fully capitalized, or is the subsidiary of a larger “deep pocketed” organization, consider requesting a parental guaranty. Guaranty agreements typically include a payment guaranty requiring the guarantor to stand behind the guaranteed party’s payment and indemnification obligations, and/or a performance guaranty requiring the guarantor to perform obligations under the agreement if the guaranteed party fails to perform its obligations. A guaranty ensures you can compel the guarantor to perform the guaranteed payment or performance obligations if the party with which you are contracting fails to comply with its payment and performance obligations. There are many tricky provisions in a guaranty, so ensure you use good counsel to help you construct the guaranty. The guaranty should survive the termination or expiration of the underlying agreement for as long as guaranteed obligations survive. Also, if you are considering a parental guaranty, think about whether it would make more sense to contract directly with the parent and not the subsidiary (which would eliminate the need for the guaranty).

7. Mitigate risk through internal processes.

When evaluating the impact of a business risk, consider whether the risk can be mitigated through existing or new business processes. Are there administrative, technical and physical safeguards or processes in place at your company, or that could easily be put in place, that would reduce the chance of a risk exposure? For example, suppose a contract requires that your software is free of viruses, spyware, malware, and the like. If you have existing technology in place to scan your software for viruses, or can easily put it in place, you may feel comfortable taking this risk as the risk of an exposure is mitigated. However, be careful implementing a manual process to mitigate risk — they can be prone to error as they are often dependent on employees manually adding a few tasks to their already crowded plate. Even if a manual risk mitigation process is well documented, it may just be replacing one type of risk with another.

8. Mitigate risk through third party certifications.

Another risk mitigation approach is to require your business partner or vendor to maintain and certify compliance with third party certifications or industry standards which demonstrate that the partner or vendor has implemented steps reasonably designed to protect your company against certain risk exposures. For example, if a partner or vendor will be handling personal information or sensitive confidential information, consider asking for a SOC 2 Type 2 report which is a statement of the effectiveness of a company’s non-financial controls. It’s important to require an unqualified report — a qualified report means that one or more of the controls covered by the report are not effective and the report should not be relied upon in that area. Other common certifications include ISO 27001 for information security management systems, SOC 1/SSAE16 for financial controls, and HITRUST certification for HIPAA business associates.

9. Mitigate risk through your own insurance.

Consider whether your existing or other available insurance coverage would protect you against certain risks arising from your partner/provider relationships. Review the biggest risks faced by your company (including risks impacting your partner/provider agreements) on a regular basis to determine if changes to your insurance coverage profile are warranted; your coverage should evolve as your business evolves. Understand what exclusions apply to your insurance. Consider asking your broker to walk you through your coverage on an annual basis.

10. Mitigate risk through contract provisions.

Finally, consider mitigating risk with your business partners through contractual provisions other than limitation of liability. For example, consider requiring your business partner agree to agree not to engage in risky behaviors, or to not provide you with data types you don’t want to receive (e.g., trade secrets, PCI data, HIPAA data). Include appropriate representations, warranties and covenants applicable to your business partner, and ensure yours are not overbroad. Consider your rights in the event of non-payment under the agreement. Consider whether an escrow provision would help mitigate risk. Consider rights to injunctive relief (including whether to waive posting a bond or other security, or proof of actual damages). Financial and security audit rights may be important. Ensure your business partner has implemented its own strong risk reduction strategies, such as implementing a business continuity plan/disaster recovery plan and anti-phishing training.

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 through supply solutions to expand product assortment, demand solutions to promote and sell products on the channels that perform, and delivery solutions to enable rapid, on-time customer delivery. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice. Eric works primarily from his home office outside of Minneapolis, Minnesota. He is a technophile and Internet evangelist/enthusiast. In his spare time, Eric dabbles in voice-over work and implementing and integrating connected home technologies.

The Wayback Machine: Portal to the Internet’s Past, and Essential Business and Legal Tool

Posted onMarch 13, 2017 by admin

The World Wide Web has revolutionized the world as an information communication medium, but it has one significant drawback – no long-term memory. Once a web page is updated or removed, it disappears as if it was never there. The Wayback Machine, named after Mr. Peabody’s WABAC machine from Rocky & Bullwinkle and located at http://www.archive.org/web, was conceived to give the Web a long-term memory. It is a tool for looking at previous versions of a web page by viewing different iterations captured over time. Internet enthusiasts can easily spend hours peering back in time to what web pages looked like “back in the day.” For example, Google’s November 1998 search page boasted about having 25 million indexed pages, “soon to be much bigger” – it’s likely even Google could not imagine how true that would be!

The Wayback Machine is operated by the Internet Archive, a non-profit organization created in 2001 for the purpose of building and maintaining a historical record of the Web. It has been “crawling” web pages and other Internet-accessible content for archiving purposes since 1996, serving as an “archaeological history” of websites. As of March 5, 2017, the archive contains 279 billion web pages, but not everything on the Web is preserved in the Wayback Machine. It visits web pages for archiving purposes on a periodic basis, ranging from weeks to hours depending on the website; it respects requests not to archive web pages if specified by the website owner (e.g., by using a “robots.txt” file); it also does not fully archive dynamically generated web pages, such as those with web forms or JavaScript; and it does not archive websites which require a login.

Aside from letting people look back at their favorite website’s beginnings or remember what a favorite long-dead site was all about (I still love pets.com‘s slogan, “because pets can’t drive”), there are a number of practical business and legal uses for the Wayback Machine. These include:

Business Intelligence

Individuals and companies can use the Wayback Machine to search for information on persons, companies and products/services, especially where the companies, products or services no longer exist or the information sought about them is no longer available online. For example, if you are looking for information about a technology, product or program offered or licensed by your company years ago, and you can’t find information about in company records (the project manager has left the company, records have been purged under the records retention policy, the company that offers it is out of business, etc.) or want to supplement what you have located so far, the Wayback Machine may have an archived version of a page from your website with the information you’re looking for.
Similarly, if you are researching a prospective client, partner or acquisition target, looking at the client, partner or target’s historical websites through the Wayback Machine can yield valuable information, such as details on the history and development of the company and its products/services. This information can identify topics to ask about during due diligence, and can help you identify representations, warranties and covenants for inclusion in a sales, partnership or purchase agreement.
If you are researching a new potential executive or potential board member, use the Wayback Machine to look at historical bios on archived websites of his or her former companies as part of a thorough due diligence process or to verify information before including it on a company website or in a securities filing.

Contracts

The Wayback Machine can help in locating missing copies of license agreements, e.g., for previously licensed software such as a software program or font acquired years ago. If you can’t find the agreement and the company from which it was acquired no longer has it on their website or has gone out of business, the Wayback Machine may help you locate a copy of the agreement from the archived version of the website around or following the date on which you acquired the licensed material, enabling you to ensure you understand your or your company’s rights to the licensed materials.
The Wayback Machine can also help locate prior versions of online agreements, such as vendor agreements. For example, if you are renewing your agreement with a large vendor who sends you a new contract available on their corporate website, and you can’t find the old version of their contract you signed years ago, use the Wayback Machine to find the old version on an archived version of their website to generate a redline against the new agreement to facilitate your review of the new agreement.

Records Retention

If a company is reconstructing their historical records, the Wayback Machine is a great place to start. Companies often find that their historical records are spotty, especially in the time before a formal records retention process was put in place. Companies may not have a policy to archive and save information of historical or business value, which may be lost over time. Use the Wayback Machine to find and save historical versions of website policies such as Terms of Use, Privacy Policy, Terms of Sale, and other website disclosures, as well as historical information such as bios on former executives and directors and product information.

Intellectual Property and Litigation

The Wayback Machine can be an excellent source of information which may be valuable or essential to a party’s position in intellectual property disputes and litigation. For example, Wayback Machine pages can be used to establish or substantiate infringing activity by a person or entity. They have also been admitted in business litigation as far back as 2003 as evidence of a parties’ course of performance.
Pages from the Wayback Machine have been used in patent litigation as prior art, i.e., a printed publication describing an invention which publication is shared with a third party (e.g., made available to the public) prior to the date on which the “inventor” filed for patent protection for that invention, and have been used to establish a first date of use in commerce for trademark purposes. (It’s important to note that the Wayback Machine only shows the date on which a page was archived, not the date it was first made accessible online.)
The Wayback Machine is also an excellent source for strategic direction in discovery or when preparing a subpoena. Reviewing a discovery or subpoena recipient’s historical websites can help refine a company’s requests for production of documents, interrogatories or other discovery requests where the subject of the request is historical or aged information. It can also help identify potential witnesses who have knowledge as to facts central to the litigation, e.g., a former employee mentioned in a historical blog post.
Many federal courts have admitted Wayback Machine web pages in court, in some cases requiring an affidavit authenticating the archived web page, or in other cases where an employee of the company hosting the original web page attests to its authenticity as a true and accurate reproduction of the original page – the ideal person is the person who created the original page, or has first-hand knowledge of the original page. The Internet Archive can provide an affidavit authenticating Wayback Machine printouts for a fee as described on its website, but strongly recommends that a party first request judicial notice or ask the other party to stipulate to the authenticity of printouts from the Wayback Machine (this can be a good approach in arbitration). Note that seeking to admit Wayback Machine web pages can lead to evidentiary objections such as hearsay. Attorneys may want to consider asking their expert witnesses about their familiarity with the Wayback Machine and whether they have previous experience in testifying as to Wayback Machine pages.
A prominent example of the Wayback Machine’s value in litigation is the Kleargear.com case. Kleargear.com instituted a provision in its Terms of Use preventing a consumer from taking any action, including posting a review, that negatively impacts the company or its reputation, and imposing a $3,500 “fine” for Kleargear’s legal fees to sue the consumer for breach of the Terms of Use. John and Jen Palmer had a negative experience purchasing a product from Kleargear.com in 2008 and left a negative review. Years later in 2012, Kleargear.com demanded payment from the Palmers of the $3,500 fine if the negative review was not removed and turned the amount over to collections when it was not paid, resulting in an impacted credit rating for the Palmers. Aside the Palmers winning the inevitable litigation they filed against Kleargear.com, the lawsuit led to legislation in California in September 2014, and federal legislation in December 2016, prohibiting anti-disparagement clauses in consumer contracts. One of the key facts in the case and in press coverage was the fact that according to the Wayback Machine’s archived Kleargear.com site from 2008, the non-disparagement clause wasn’t even part of the Terms of Use at that time (it was added to the site later on).

Business Tools

The Internet Archive offers useful business tools. For example, consider the Wayback Machine’s 404 error page handler. The 404 error page handler enables a website to offer an archived version of a page from the Wayback Machine if a current page is not found and an archived version exists in the Wayback Machine. This can help reduce the impact of 404 errors for websites where content of web pages does not change too quickly, and where displaying an older page is better than no page.
The Internet Archive also offered an archiving service called “Archive-It” which companies can use to collect, catalog, manage, store, and provide 24/7 online search of and access to archived content collections. If your company or organization wants to preserve a collection of online content, consider using this service. Users include museums and art libraries, NGOs, colleges and universities, other private companies and non-profits.

Access the Wayback Machine at http://archive.org/web. Frequently-asked questions are located at https://archive.org/legal/faq.php. If you don’t find the Wayback Machine to be a useful business and legal tool, you can at least take a stroll down Internet memory lane.

7 Tips for Implementing a Records Retention Policy Employees Will Follow

Posted onFebruary 2, 2017 by admin

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.

The Rewards and Risks of Open-Source Software

Posted onFebruary 15, 2016 by admin

Open-source software (or “OSS”) is computer software distributed under a license whose source code is available for modification or enhancement by anyone. This is different than free (or public domain) software, which is not distributed under a license. Free and open-source software are alternatives to “closed source,” or proprietary, software.

Companies use OSS for a variety of reasons. In some cases, it’s used as part of a project deliverable, such as a DLL or a JavaScript library. In others, it’s used as a tool as part of the development process or production environment, such as a compiler, development environment, web server software, database software, etc.

The Rewards of OSS. There are significant benefits to using open-source software in your business. Here are some of the most significant:

Enhanced Security.Anyone can modify and enhance OSS, resulting in a larger developer base than proprietary software. This means that security holes are often found more quickly, and patched more quickly, than proprietary software.
Lower Cost. There is no license fee for open-source software. (That does not mean it’s totally free – OSS is subject to license requirements.)
Dev Cycle Streamlining. Using OSS in a project cuts down development time by allowing developers to avoid “reinventing the wheel” on needed code if an OSS version of that code is available.
Perpetual Use. As long as you abide by the terms of the open-source software license, you can generally use it forever. There are no annual renewal fees or license renegotiations for mission-critical software.
Adaptability/Customizability. Users of closed source software must find the software package that most closely aligns with the business’ needs, and adapt to it. There’s no need to settle with OSS – since it can be customized and adapted, you can start with the existing code and modify it to fit your company’s exact needs.
Better Quality. Since there is a larger developer base, new and enhanced features and functionality are often rolled out, and usability bugs fixed, at a more rapid rate than in proprietary software.
Support Community. Many common closed source software packages require the purchase of a maintenance subscription along with a license. Well-used OSS has a robust developer community that can help with questions.There are also companies that have sprung up around common OSS packages to provide support solutions.

Know Your OSS Licenses.�The author of software code owns the copyright to that code. If the author released software into the public domain, he/she is waiving his/her copyrights in that code, making it free for anyone to use. However, if someone creates a derivative work of public domain code, the new portions of code are protected by copyright, and are not in the public domain. In other words, by adding his/her own modifications, someone can take public domain software and make it proprietary.

That’s the primary difference between free software and OSS. In most cases, when an author makes his/her software code open-source, that author is allowing use of his/her copyrighted code under an open-source software license, but is not relinquishing his/her copyright. Under the OSS license, the author grants others a right to use the author’s copyrighted code to modify, copy and redistribute it, but only if they follow the terms of the open-source software license. There are hundreds (or more) open-source licenses out there. However, there are relatively few that are considered generally accepted with a strong developer community. The Open Source Foundation (OSF) categorizes the most common OSS licenses here. The most common are the GNU General Public License (GPL), the GNU Lesser General Public License (LGPL), the “New” BSD License, the “Simplified” BSD License, the MIT License, and the Apache License v2. However, not all OSS licenses are the same. There are many websites that can help you analyze the differences between OSS licenses, including tl;dr Legal and Wikipedia’s Comparison of Open-Source Software Licenses.

Many OSS licenses are “permissive” licenses, meaning that a work governed by that license (e.g., a BSD License) may be modified and redistributed under a different license as long as you comply with the requirements of the permissive license (e.g., attribution). Other OSS licenses are “copyleft” licenses. A copyleft license is one under which a work may only be used, modified or distributed if the same license rights apply to anything derived from it. The copyleft license will “infect” modifications and derivations of the source (some think of it as a “viral” license). It’s a play on words as copyright and copyleft are converse terms: copyright gives exclusive rights to a work to one person, and copyleft gives non-exclusive rights to a work to everyone. There are two types of copyleft licenses:

“Strong” copyleft licenses (e.g., the GNU GPL) state that if you modify code governed by a copyleft license, you must distribute the software as a whole under that copyleft license, or not distribute it at all.
“Weak” copyleft licenses (e.g., the GNU Lesser GPL) state that if you modify code governed by a copyleft license, portions of the software containing modifications (e.g., a software module or library) must be distributed under that copyleft license, but other portions may be distributed under a different license type.

The Risks of OSS. Due to its benefits and rewards, most companies use open-source software, whether the management and Legal teams know it or not. Quite often, developers rely on OSS to deliver software development projects on time and within budget. The bigger question is whether developers are using OSS in a way that exposes the company to risk. Unless your company has a well-defined OSS policy that has been well-communicated to the developers at your company, you’re “flying blind” when it comes to OSS usage. Here are some of the risks and considerations for companies using OSS:

OSS makes more sense for “utility layer” software needs than for “competitive/proprietary layer” software needs.Think of the software used in business as two layers. The first is software at the “utility layer” – software packages that go to the general operation of the business and its IT infrastructure, and do not give the business a competitive advantage based on the code itself. Examples are web server software, database software, and standard APIs. Above that is the software at the “competitive/proprietary layer” – software that gives your company a competitive advantage you’re your competition, or provides significant offensive or defensive IP protection. Examples are custom functionality on your website and specialized software applications. OSS makes a lot of sense at the utility layer – you don’t need something better than everyone else, just something that works and works well. Introducing OSS at the competitive/proprietary layer can be problematic as you may want to ensure the entire solution is proprietary.

You can’t get IP warranties or indemnification for OSS.When you negotiate a software license agreement for proprietary closed source proprietary code, in most cases the software licensor will provide warranties and/or indemnification against claims of IP infringement. With OSS, there is no IP warranty or indemnity. If someone introduced proprietary code into the OSS earlier in its life, you bear the risk of infringement if you use it.

Some OSS license types can snuff out IP rights to your own developed code (and even expose it). The type of OSS license governing OSS used in your business, and how you use OSS software, can directly affect your IP rights to your own developed code. If you use OSS governed by a strong copyleft license to enhance your own codebase, your entire codebase could potentially become governed by a copyleft license. This means that a savvy competitor or customer that suspected or learned of OSS in your code could send you a letter demanding a copy of your source code under the copyleft license, or just decompile it and modify it, putting you on the defensive as to why your software license should override the copyleft open source license.

If you don’t follow the license terms, you can be sued.Open source software is licensed. That means there are license terms you must follow. If you don’t, you may face litigation from competitors or others. There has been a recent upswing in litigation for breach of the terms of open source licenses, and that trend is expected to continue. For example, VMware was sued in March 2015 alleging that it violated the GNU GPL v2 license by not releasing the source code for VMware software that used OSS subject to the copyleft license.

Implement a Company-Appropriate OSS Policy. To mitigate the risks associated with OSS, all companies should implement an open-source software policy governing the when, why and how of using open-source software in the company’s codebase. Here are some important considerations:

Ensure there is alignment on the goal of the OSS policy at the outset.Different stakeholders may have different views on the goal of an OSS policy. To Legal, it make be to protect the company’s intellectual property; to IT, it may be to leverage OSS to reduce costs; to developers, it could be to ensure they are free to keep using the OSS they need to meet goals and deadlines. One thing stakeholders cannot do is go in with the mindset that OSS is bad for business or that they can keep it out of their code. OSS in business is a reality that can either be ignored or accepted. The policy’s goal should be to ensure OSS is being used effectively to advance the company’s business objectives while protecting its IP and living within its risk profile.
An OSS policy must balance the practical needs of developers with risk management.OSS is the domain of the developer, not the Legal department. While the risks are something lawyers consider, a policy written and imposed by non-developers on your developer corps will likely face an uphill battle, or worse, be viewed as “out of sync with the goals of the business” and just ignored. The attorneys’ role in creating an OSS policy is to provide guidance on the risks of OSS to the company as a whole, provide “best practices” guidance in OSS policies, and to draft the actual policy from the outline in plain English (remember, developers, not other attorneys, are the audience). IT management’s role is to provide guidance on the outside contours of the policy. Developers need to be directly involved in developing the policy itself as they are the ones using OSS in their daily work. Developers, Legal and IT should develop the company’s OSS strategy, and its OSS policy, as equal stakeholders.
- Ensure senior management buys into the policy before it is finalized; it’s important that management understand how OSS is used in the business.
- Ensure the policy covers key topics, e.g., sourcing OSS; selecting OSS code for use at the utility layer and the competitive/proprietary layer; the OSS approval process; support and maintenance requirements; redistribution; tracking OSS usage; and audits/training.
- Ensure the policy covers independent contractor developers as well as employees.
OSS code review and approval must be a streamlined process.If the review and approval process is complicated, developers will be more likely to just skip it. Make approval easy. Provide a “pre-approved list” of OSS – certain combinations of license types, utility level software categories, and/or specific code packages that only need notification of usage for tracking purposes.
- Have a simple process for vetting other usage requests, asking the critical questions (e.g., What is the name and version number of the software package for which use is requested? What license type applies? Where was the code sourced from? Will the code be modified? What is the support plan? Will the code be distributed or used internally? What is the expected usage lifetime of the code? Are there closed source alternatives? Etc.) so that the legal and business risks can be measured and balanced against the benefits of usage.
- Determine who will do the first review and escalated review (IT, Legal).
- Turn requests quickly as delays can impact development timeframes.
Keep a database of all used OSS, including where is it used and what license type applies.Knowing what OSS you’re using is critical to avoid introducing code that has a bad reputation or is governed by an OSS license your company is not comfortable with (e.g., a strong copyleft license). IT should maintain a database of OSS used by the company, including the license type for each OSS. This database is also helpful when responding to security questionnaires and is often needed in M&A due diligence.
Other Considerations.Consider conducting quarterly or semi-annual reviews of OSS usage, e.g., questionnaires to developers. Consider having developers acknowledge the OSS policy at hire, and on an annual basis. Consider conducting OSS training if your company’s learning management system (LMS) has an available course module on OSS. And most importantly, review the OSS policy no less than once a year with all stakeholders to ensure it is evolves as the world of OSS, and the company’s own needs, change over time.

Revisiting Risk Management

Posted onOctober 12, 2015 by admin

A couple of years ago, I wrote an article on “Risk Management 101.” Risk management is not the same as risk avoidance — taking risk is an important driver of business growth. As an attorney, it’s important to recognize that “zealously representing your client” is not the same thing as insulating your client from risk. Risk in business is like risk in investing; you have to be willing to take a loss if you want to achieve solid growth, and your appetite for risk determines how much risk you’re willing to take. Any risk management decision is a decision on whether or not to proceed with a particular course of action (or inaction) given the balance between the potential benefits and the potential risks. Given the importance of risk management, I thought it was time to revisit the topic.

What to do with business risk. Once you’ve identified a business risk, there are four things you can do with it:

Mitigate it�by following or implementing technical, administrative or procedural steps or safeguards, or best practices, to reduce your company’s exposure to the risk;
Shift it by making another party responsible for the risk exposure through contract terms (e.g., representations and indemnification, liquidated damages, etc., requirements to be named as an additional insured or loss payee under the other party’s insurance), or through obtaining your own insurance;
Reject it�by walking away from the proposed course of action or inaction that causes the business risk; or
Accept it by proceeding with the proposed course of action or inaction knowing it could cause an exposure based on the business risk.

When faced with a business risk that calls for a risk management decision, you should first reduce the risk, then decide what to do with the remaining risk.

To reduce the risk, the attorney will partner with his or her business counterparts to mitigate and shift as much of the risk as possible. For example, the attorney will work with business owners to determine if there are procedures in place to control the risk, or whether procedures could be put in place to help control the risk. The attorney will work with the company’s insurance group to see if its insurance will cover the risk. If the risk is arising in the context of a contract, the attorney will work to incorporate risk shifting provisions into the agreement to control the risk. The goal is to reduce the risk as much as possible, but be mindful that there can be an ROI impact here. If mitigating a risk through new processes, new insurance premiums, etc. increases the cost to the business, the overall costs from taking the course of action is impacted.
Once the risk has been reduced, a decision has to be made to accept or reject the remaining risk. Unless the risk relates to a violation of law, the attorney will turn to the business decision-maker to call the ball. When presenting a risk decision to the decision-maker, (1) describe the business risk; (2) explain what risk mitigation steps will be implemented or taken; (3) explain the potential costs related to the remaining risk (both tangible, e.g., cost, and intangible, e.g., impact to the business), and the benefits of the course of action; and (4) let the business decision-maker call the ball. This way, the business decision-maker can make an informed business risk decision. The amount of detail you go into is often driven by the speed at which the decision needs to be made. If a decision must be made quickly, you may not have the time to explore risk mitigation steps first, in which case you can describe the mitigation steps that could be taken. Consider your audience — be as concise as possible in describing the costs and benefits to management. Make sure the person that is approving or rejecting the risk has the authority to do so within the organization. Lastly, the attorney and business person should ensure that the risk management decision is documented in case an issue arises later on.

What to do if a risk exposure occurs. While the initial instinct when something bad happens is to assess blame, an authorized decision-maker who makes a well-informed business risk decision should not be “thrown under the bus” if the risk exposure ultimately occurs. If proper risk management procedures are followed, the exposure should result in a review of the risk management decision to see if other “hindsight” data points would have impacted the risk management decision if known at the time, and determine if changes to the decision-making process or the company’s risk profile are appropriate on a go-forward basis. Risk exposures will happen in business. If a decision-maker is disciplined (or worse) in the event of an exposure just for making the business risk decision, even if the benefits far outweighed the potential risks at the time the decision was made, the company will send the message that good risk management practices don’t matter to management. Reward those who follow good risk management practices.

Accepting a business risk is the same thing as electing to self-insure against the risk. If you don’t identify and manage a risk, your business is accepting the entire risk without any mitigation steps. For small risks, this usually doesn’t cause a problem. For bigger risks, this can be catastrophic. Understanding, implementing, and fostering solid risk mitigation practices at your company can make all the difference.

FTC opens their nationwide tour to promote Start with Security

Posted onSeptember 16, 2015 by admin

It’s not the latest group on tour with a band name and album name that needed a lot more thought. Earlier this year, the FTC announced that they would be releasing guidance for businesses on data security. In June, they did just that, releasing a guide called Start with Security: A Guide for Business. It’s subtitled “Lessons Learned From FTC Cases” for a reason — it uses the 50+ FTC enforcement actions on data security to provide ten lessons companies should learn when approaching to security to avoid others’ missteps that led to enforcement actions, and practical guidance on reducing risks. The lessons are:

Start with security. The FTC has long advocated the concept of “privacy by design,” meaning companies should bake an understanding of and sensitivity to privacy into every part of the business, making it part of the design process for new products and processes. The FTC is advocating a similar concept of “security by design.” Guidance: don’t collect personal information you don’t need (the RockYou enforcement action); don’t use personal information when it’s not necessary (Accretive and foru International); don’t hold on to information longer than you have a legitimate business need for it (BJ’s Wholesale Club).

Control access to data sensibly. Keep data in your possession secure by controlling access to it – limit access to those with a need to know for a legitimate business purpose (e.g., no shared user accounts, lock up physical files). Guidance: don’t let employees access personal information unless they need to access it as part of their job (Goal Financial); don’t give administrative access to anyone other than employees tasked administrative duties (Twitter).

Require secure passwords and authentication. Use strong password authentication and sensible password hygiene (e.g., suspend password after x unsuccessful attempts; prohibit common dictionary words; require at least 8 characters; require at least one upper case character, one lower case character, 1 numerical character, and 1 special character; prohibit more than 2 repeating characters; etc.) Guidance: require complex and unique passwords (Twitter); store passwords securely (Guidance Software, Reed Elsevier, Twitter); guard against brute force attacks (Lookout Services, Twitter, Reed Elsevier); protect against authentication bypass�such as predictable resource location (Lookout Services).

Store sensitive personal information securely (“at rest”) and protect it during transmission (“in motion”). Use strong encryption when storing and transmitting data, and ensure the personnel implementing encryption understand how you use sensitive data and can determine the right approach on a situation-by-situation basis. Guidance: Keep sensitive information secure throughout the data life-cycle (receipt, use, storage, transmission, disposal) (Superior Mortgage Corporation); use industry-tested and accepted methods (ValueClick); make sure encryption is properly configured (Fandango, Credit Karma).

Segment your network and monitor who’s trying to get in and out. Be sure to use firewalls to segment your network to minimize what an attacker can access. Use intrusion detection and prevention tools to monitor for malicious activity. Guidance: segment your network (DSW); monitor activity on your network (Dave & Buster’s, Cardsystem Solutions).

Secure remote access to your network. Make sure you develop and implement a remote access policy, implement strong security measures for remote access, and put appropriate limits on remote access such as by IP address and revoking remote access promptly when no longer needed. (The compromise of a vendor’s system via phishing, leading to remote network access, is how the Target breach started.) Guidance: ensure remote computers have appropriate security measures in place, e.g., “endpoint security” (Premier Capital Lending, Settlement One, LifeLock); put sensible access limits in place (Dave & Buster’s).

Apply sound security practices when developing new products. Use “security by design” to ensure data security is considered at all times during the product development life-cycle. Guidance: Train engineers in secure coding (MTS, HTC America, TrendNet); follow platform guidelines for security (HTC America, Fandango, Credit Karma); verify that privacy and security features work (TRENDnet, Snapchat); test for common vulnerabilities (Guess?).

Make sure your service providers implement reasonable security measures. Make sure you communicate your security expectations to your service providers and vendors, and put their feet to the fire through contractual commitments and auditing/penetration testing. Guidance: put it in writing (GMR Transcription); verify compliance (Upromise).

Put procedures in place to keep your security current and address vulnerabilities that may arise. Data security is a constant game of cat-and-mouse with hackers – make sure to keep your guard up. Apply updates to your hardware and software as they are issued, and ensure you are spotting vulnerabilities in, and promptly patching, your own software. Have a mechanism to allow security warnings and issues to be reported to IT. Guidance: update and patch third-party software (TJX Companies); heed credible security warnings and move quickly to fix them (HTC America, Fandango).

Secure paper, physical media, and devices. Lastly, while the focus these days seems to be on cybersecurity, don’t forget about physical security of papers and physical media. Guidance: securely store sensitive files�(Gregory Navone, Lifelock); protect devices that process personal information�(Dollar Tree); keep safety standards in place when data is en route (Accretive, CBR Systems); dispose of sensitive data securely (Rite Aid,�CVS Caremark,�Goal Financial).

As this guidance is based on what companies did wrong or didn’t do that led to FTC enforcement actions, it will be interesting to see how the FTC treats a company that suffers a data breach but demonstrates that they used reasonable efforts to comply with the FTC’s guidance. I suspect the FTC will take a company’s compliance with this guidance into consideration when determining penalties in an enforcement action. The guidance is very high-level, so companies must rely on their IT and Legal teams to determine what steps, processes and protocols need to be implemented in alignment with the FTC’s guidance.

In addition to publishing the guide, the FTC has embarked on a conference series aimed at SMBs (small and medium-sized businesses), start-up companies, and developers to provide information on “security by design,” common security vulnerabilities, secure development strategies, and vulnerability response. The first conference took place September 9 in San Francisco, CA; the second will take place November 5 in Austin, TX.

The FTC also announced a new website at which they’ve gathered all of their data security guidance, publications, information and tools as a “one-stop shop”. You can find it at http://www.ftc.gov/datasecurity.

Podcast – the in-house perspective on trade secrets, privacy, and other topics

Posted onSeptember 4, 2015 by admin

I recently had the privilege of being interviewed for IP Fridays®, a podcast series by Ken Suzan (of counsel and a trademark attorney at the Minneapolis office of Barnes & Thornburg LLP, and Dr. Rolf Claessen, partner at Patent Attorneys Freischem in Cologne, Germany. We discussed the in-house perspective on a variety of topics, including trade secrets, copyrighting software code, and privacy. Head to IPFridays.com if you’d like to listen, or click here to head straight to the podcast.

Don’t Overlook Law Firms as Third-Party Data Storage Vendors

Posted onAugust 4, 2015 by admin

There are countless articles providing companies with tips and advice on what to look for, and what to look out for, when engaging with a vendor who will store, process and/or use company data and/or network credentials. Given recent high-profile data breaches attributable to vendors of major companies, there has been a focus on tightening controls on vendors. Many companies have put procedures and requirements in place to ensure that vendors storing company data and network credentials are properly vetted, meet IT and security standards, and commit contractually to protect the company’s valuable information.

Despite this, there is one group of vendors storing data that are overlooked by a large number of companies – law firms. Here are a few reasons why:

Engagements don’t follow the usual vendor procurement process. Law firms are generally engaged directly by the General Counsel, other senior attorneys, or senior management. They are usually engaged due to their specialized expertise in a particular area of law in which there is an immediate need, an existing relationship with a member of the legal or management team, or a recommendation by a trusted resource. Law firm engagements often happen at the same time there is a pressing need for their services (e.g., a pending response to a complaint) with little time for a selection process. Quite often, companies don’t use a formal bid process at all when engaging outside counsel.

Law firms don’t think of themselves as just another vendor. Law firms generally do not consider themselves to be like other vendors given their specialized role and partnership with companies to provide legal advice and counsel. They are like other service companies in some respects (for example, law firms need to comply with federal, state and local laws, rules and regulations applicable to other companies). Unlike other service companies, the lawyers providing services at a law firm are also bound by rules of professional responsibility with disciplinary measures for noncompliance. These rules include obligations to keep client information confidential. The Model Rules were recently changed to add obligations for law firms to use reasonable efforts to protect client data, and to keep abreast of the benefits and risks associated with relevant technology involved in the practice of law.

When a law firm suffers a major breach exposing customer data and notifies clients in compliance with state breach notification statutes, it will be interesting to see whether lawyers in that firm face disciplinary action under rules of professional responsibility for exposure of client data. If lawyers face discipline as the result of a security breach, it will bring security to the forefront of client-lawyer relationships overnight.

Other teams within a company consider law firm relationships as “off limits.” Legal often only reaches out to IT for assistance arranging secure transfer of files to and from law firms, and in connection with discovery requests. It’s very rare that procurement and IT teams reach out to Legal to ask them to run law firms through the same vetting process as other vendors handling company data or system credentials, and its’ equally rare for Legal to proactively request this review of the law firms it engages.

Things You Should Do. When your company engages a law firm, consider the following:

Proactively develop internal vetting requirements. Your Legal, IT, Security and Procurement teams should proactively develop a checklist of questions/action items/contractual requirements when engaging counsel. If engaging counsel in a hurry, make sure the firm realizes that your company will do this diligence as soon as possible following engagement.

Ask the firm about their security safeguards. When discussing an engagement with prospective counsel, ask them what their technical, administrative and procedural safeguards are for protecting your information (and, if you give them network access, your network credentials). Find out how big their information security team is, and what kind of systems they use. You’re relying on their security safeguards to keep your data safe, so it’s appropriate for you to ask questions about how they secure your data.

Law firms have historically been reluctant to talk about their information security practices.If a firm can’t give you solid information about their information security practices, or can’t give you the name of a person who can answer your IT and security questions, strongly consider looking for alternative counsel.

Ask about cyber insurance. Ask whether the firm carries cyber insurance to cover security breaches (more and more firms have it). If they do, ask them to add you as an additional insured as you would with other vendors holding your data.

Add a security rider to your law firm engagement letter, security language to your outside counsel guidelines, or both. Add a short rider to your law firm engagement letter with the security language you came up with in advance with your IT and security teams. Consider addressing topics such as security and confidentiality safeguards, requirements to rapidly deploy security patches to their hardware and software, and confidentiality of login credentials to your network.Ensure they are protecting you if there is an unauthorized disclosure of your company data stored through a third party system or provider they use.

Companies often ask counsel to comply with their outside counsel guidelines, and many ask clients to agree to compliance as part of the retainer letter. Include core security language in your engagement letter, and include an paragraph in the retainer letter requiring the law firm to follow the terms of your outside counsel guidelines (and resolving conflicts in favor of the guidelines).

It’s a matter of if, not when, a law firm announces a major security breach. Once that happens, it will cause a seismic shift in how law firms approach data they hold, and how prospective clients engage with them. Law firms that take a proactive approach and make their commitment to data security part of their core client values, and are willing to share their commitment with prospective clients, will find themselves with a leg up on the competition.