Posted in Cross-Border Transfers

Cross-Border Considerations for Protecting IP Developed by Employees and Independent Contractors

Is your startup considering hiring software developers in a foreign country to work on the latest version of your app?  Is your company considering acquiring an entity with employees who have developed intellectual property (“IP”) in non-U.S. jurisdictions?  From hiring independent contractors or employees (each may be referred to in this post as “Contributors”) to conducting diligence on the IP terms in employment agreements or confidential information and invention assignment agreements, the IP related issues to consider in non-U.S. jurisdictions may be unexpected for those used to working only with Contributors in the United States.

Assignment of IP Rights

In the United States, many employers rely (i) on broadly drafted provisions assigning all IP developed by a Contributor in the course of the engagement with the employer to the employer and/or (ii) work made for hire principles under the U.S. Copyright Act (17 U.S.C. §§ 101 et seq.) (“Copyright Act”) to ensure the work developed or invented by the Contributor is assigned to the employing entity.  Under the Copyright Act, a work is a “work made for hire” if: (1) it is prepared by an employee within the scope of his or her employment, or (2) it is specially ordered or commissioned from an independent contractor pursuant to a written agreement and the work falls within one of the statutorily defined categories.

In other jurisdictions, however, work made for hire principles may not exist and broad present assignment provisions are not always enforceable under local law. The scope of protectable IP rights and when such rights are considered to have been developed within the scope of employment or contractor duties varies across the globe, so the definitions of the IP and other rights assigned should be reviewed to ensure the broadest application possible in the applicable jurisdiction. In particular, local laws in some European countries (e.g., France and Germany) prohibit assignment of an author’s copyrights and/or moral rights in a work either entirely or prohibit such rights from vesting initially in the employer.

Further, fallback provisions used in the U.S. to provide rights to the employer in the event certain rights may not be assigned or licensed, such as provisions in which the Contributor (i) grants the employer an exclusive license to IP that cannot be assigned to the employer under applicable law (i.e., a “waterfall license”), and (ii) agrees not to assert the Contributor’s rights in any IP that cannot be assigned or licensed by the Contributor to the employer under applicable law, may also not be enforceable (at least prior to the development of the applicable IP). Similarly, local law may limit the application of license grants by the Contributor to the employer for IP that is developed prior to the start of the Contributor’s engagement with the employer, or outside of the scope of the engagement with the employer but integrated into or necessary for the use of the IP assigned to the employer.

In such cases, a broad U.S. style assignment or license provision may be thrown out by local courts leaving the employer without the desired or necessary rights in the Contributor’s work. An attorney in the relevant jurisdiction may provide guidance as to whether a waterfall license is standard and enforceable in the applicable jurisdiction and whether a waiver of non-assignable and non-licensable rights is enforceable or a preferable alternative to a waterfall license.

Claiming IP 

Local law may require special steps, documents, processes or procedures for the employer to “perfect” or “claim” its ownership interest in the IP assigned by a Contributor to his or her employer. For example, certain jurisdictions require employees to notify the employer of IP developed or created within the scope of employment or require the employer to “claim” such IP within a certain period of time after the employee’s disclosure (e.g., four months) in order for the employer to own the IP. Counsel in the local jurisdiction may recommended the development of template disclosure or claim documents and policies for employees to notify the employer of the IP they develop or create (some of which may be mandatory under local law).

Additionally, there may be registration requirements or other documents to be submitted to government or regulatory agencies a result of the performance of the Agreement (e.g., documenting payment for services to independent contractors or upon assignment to the employer of the IP and technology resulting from such services). Companies engaging an entity as a consultant, should consider including a provision in the consulting agreement requiring the consultant to comply with any notice, claim, or registration requirements for IP created by the consultant’s Contributors. The risk of a failure to comply with any applicable notice, claim, or registration requirements can include that the employer is deemed to have given up its ownership right to the relevant IP. So, local requirements should be closely reviewed and followed.

Inventor Remuneration Payments

Local law may require special payments (other than wages and salary), known as inventor compensation or inventor remuneration, to employees as consideration for the employees’ assignment of certain IP to the employer. Such inventor remuneration may be dealt with in contractual provisions between the employer and the employee, however, in certain jurisdictions outside of the U.S., employers may not contract around mandatory minimum remuneration requirements. Particularly, inventors of patents are often due inventor remuneration at various stages of an invention’s life cycle (e.g., disclosure to employer, filing of patent application, grant of patent, etc.). Failure by the employer to make inventor remuneration payments when due may give the affected employee(s) the right to make a wage claim against the employer. Counsel in the local jurisdiction should be consulted to determine whether such inventor remuneration payments need to be addressed in employment documents, how the payments may be calculated, and when the payments are due to employees.

Mandatory Local Law

Selecting a favorable governing law, such as the state where your company’s U.S. entity is organized, in an agreement may not be sufficient to avoid the application of local law where the employee is employed or the contractor performs services (i.e., where the agreement is performed). Such local law and mandatory provisions under local law may be applicable despite a choice of governing law in the agreement. As a result, in addition to the other potential local law consequences discussed here, contractual provisions that may appear in U.S. forms, such as indemnification of the employer and post-term survival of certain provisions, may be unenforceable against the Contributor in the jurisdiction where the agreement is performed. Even where governing law of an agreement is in the U.S., it is always prudent to confirm with counsel in the local jurisdiction that the local law of the jurisdiction where Contributors perform the agreement is not applicable.

Other Practical Considerations: Translation, Further Assurances

After final agreement between the employer and Contributor on the terms of an agreement, local law or custom may dictate that the agreement be translated.  Be sure to budget additional time for translation of the agreement into the local language or a bilingual version as necessary or recommended by counsel in the local jurisdiction.

Also consider the possibility that it may be much more difficult, after the termination or expiration of the agreement, to find a former Contributor residing in another country.  As such, ideally, all necessary documents should be executed during the relationship with the Contributor. A further assurances clause (i.e., where a Contributor agrees to provide additional assistance to execute IP assignment documents and the like, after performance of the services) may not be of much use if you are unable to locate the Contributor.  If advised by local counsel, an irrevocable power of attorney clause permitting the employer to act on behalf of the Contributor in executing documents necessary to effectuate the underlying agreement may be useful in case the Contributor cannot be located in the future.

In Summary…

In conclusion, consulting a local attorney may save you the unpleasant surprise of realizing further down the road, such as, in an acquisition, dispute, or when trying to enforce IP rights, that you do not own the work you paid a Contributor for. In many cases, it may be too late to find the former Contributor to address the issue post-hoc.  As the saying goes, an ounce of prevention is worth a pound of cure.

 

Posted in Cybersecurity New Privacy Laws Privacy and Data Security US State Law

New Mexico becomes 48th state to enact a data breach law, plus US state-level updates

Written by Jim Halpert and Anne Kierig

An active spring state legislative session has already produced a few new state data breach laws.

Notably, when New Mexico HB 15 was signed into law on April 6, the state became the 48th in the nation to have a data breach law on the books. The only holdouts: South Dakota and Alabama.

Unlike most state data breach laws, New Mexico includes “biometric data” in its list of “personal identifying information” that triggers breach notice.[1] If a court determines that a person covered under the bill violated the statute knowingly or recklessly, the court can penalize the person the greater of either $25,000 or, in the case of failed notification, $10 per instance of failed notification, up to a maximum of $150,000.

The notice requirement both to residents and to the Attorney General (AG) (in the event of a breach to more than 1,000 New Mexico residents) is “in the most expedient time possible, but not later than 45 calendar days following discovery of the security breach.” The new law will take effect on June 16, 2017.

Updates across the states

A handful of other states also updated their data breach laws this year. In what may be a harbinger of bills in other states next year, Virginia HB 2113/SB 1033 requires employers and payroll service providers to notify the state AG when data that was breached includes tax information that can be linked to a specific individual. The AG will then provide notice of that breach to the state Department of Taxation. The law goes into effect on July 1, 2017.

Tennessee SB 547 clarifies that a breach of encrypted data does not require notice under Tennessee’s law. A law enacted last year in the state was somewhat unclear on this point. Tennessee’s breach notice law remains in the minority that do not include a “harm trigger,” meaning a breach of sensitive personally identifiable information requires notice, even if it does not create risk of identity theft or fraud. The new law went into effect on April 4, 2017.

Arkansas SB 247, which is scheduled to go into effect on August 3, 2017, requires entities engaged “in the business of insurance” (an undefined term), to provide breach notice to the Insurance Commissioner.  The notice must be provided in accordance with the state’s breach notice law, “in the most expedient time and manner possible and without unreasonable delay . . . .” (Ark. Code § 4-110-105.)

A newly passed law in MarylandHB 974, adds additional types of information to the “Personal information” that may trigger a breach notice obligation under that state’s breach statute. The newly enacted law adds the following data elements to the list:

  • “Health Information,” defined as “any information created by an entity covered by the federal Health Insurance Portability and Accountability Act of 1996 regarding an individual’s medical history, medical condition, or medical treatment or diagnosis” (a different definition than in other state laws, but one that tracks HIPAA)
  • “Biometric data of an individual generated by automatic measurements of an individual’s biological characteristics such as a fingerprint, voice print, genetic print, retina or iris image, or other unique biological characteristic, that can be used to uniquely authenticate the individual’s identity when the individual accesses a system or account” and
  • “A user name or e-mail address in combination with a password or security question and answer that permits access to an individual’s e-mail account.”

The new law includes a provision requiring service providers who suffer a breach to share information relative to a breach with the party responsible for notification of the breach (i.e., the party that “owns or licenses” the personal information). The bill was signed into law on May 4 and takes effect on January 1, 2018.


[1] Biometric data is defined as “a record generated by automatic measurements of an identified individual’s fingerprints, voice print, iris or retina patterns, facial characteristics or hand geometry that is used to uniquely and durably identify authenticate an individual’s identity when the individual accesses a physical location, device, system or account.”

Posted in Uncategorized

Caps on Liability – How to Avoid it Backfiring

Written by Jeff Aronson

Imagine that you’re counsel for a software company. You draft a software license agreement’s limitation-of-liability clause to limit the liability of each party under the agreement to $5,000, notwithstanding anything to the contrary.  What do you expect would be the result if the customer refuses to pay for the $20,000 in license fees and argues that its liability is capped at $5,000?

A recent (2014) case out of Texas had this exact scenario.  The customer, a security alarm installation and monitoring service provider, had licensed software from a vendor for $20,000.  The software license agreement contained the following sentence: “NOTWITHSTANDING ANYTHING TO THE CONTRARY, THE TOTAL DOLLAR LIABILITY OF EITHER PARTY UNDER THIS AGREEMENT OR OTHERWISE SHALL BE LIMITED TO U.S. $5,000.”  The software supposedly did not function as promised.  The customer refused to pay.  When the vendor sued, the customer asserted its liability was capped at $5,000. The Texas Court of Appeals ultimately read the aforementioned cap on liability to apply just to damages caused by the “improper functioning or failure of software“ and found the contract’s ‘notwithstanding anything to the contrary’ language did not operate to limit the customer’s liability in the event it breaches the agreement by refusing to make payment.

The software vendor got lucky in this situation – a different court could just have easily concluded the other way given the breadth of the ‘notwithstanding anything to the contrary’ language.  What could have been done differently here to avoid this situation?  The vendor’s counsel could have simply carved out the customer’s express payment obligations from the cap on liability. That would have saved a lot of legal fees and wrangling over the payment.

See IHR Security, LLC v. Innovative Business Software, Inc., 441 S.W.3d 474 (2014).

Posted in Uncategorized

Cloud Transformation – How to Steer Clear of the Storms

Written by Annabel Ashby

Cloud computing is no longer new (and indeed can be seen as itself being rebadged from earlier forms of remote hosted/ASP style offerings). However, what is apparent is the continuing growth in size and sophistication of cloud deals, both in the private and public cloud space. With this comes an increased focus on the contractual and commercial terms, and a continuing challenge for perceived norms on both the customer and supplier side of the fence.

The Developing Market

For a long time, deals appeared to mostly fall into two categories:

  1. Public cloud offerings on a “one-to-many” basis, where suppliers showed little appetite to depart from standard terms of business, whether because of the need to have the contract terms reflect the common delivery model or simply by reason of a reluctance to take on additional contract risk; or
  2. Private cloud arrangements which were bespoke/specific to one (usually larger) client, where the contract terms would be fully negotiated in much the same way as a managed service/outsource style contract would be, and frequently based on the customer’s proposed contract terms.

Both of these models do, of course, still exist and have increasingly replaced more traditional forms of on premise licence and support arrangements. However, we have also seen variants which can create more of a challenge when it comes to the negotiation of contract terms. These include:

  1. “ERP in the cloud” style deals, where far more business-critical systems are proposed to be run remotely, and where the relevant software licensor is taking on both implementation and hosting services/responsibilities for the first time; and
  2. Private cloud services which – whilst “dedicated” to the relevant customer in the sense that there will be discrete instances of the relevant software and very often segregated servers/racks as well – will nonetheless be provided from shared datacentres and using shared networks, which can have an impact upon both the supplier’s ability to meet the specific service requirement of the customer, whilst also necessitating a few supplier mandated requirements as well.

Key Contractual Challenges

In the light of these developments, what forms of contractual challenges are we seeing?

  • Warranty Protections

Whilst such an approach might pass muster for a “take it or leave it” commodity-style cloud offering, it would clearly not be acceptable for a customer who is seeking to use the cloud for more business critical applications and services. Accordingly, we now commonly see the acceptance of an obligation upon the service provider to correct warranty defects as being independent of any separate right to claim compensation for related losses.

In the context of standard contract terms sent out by vendors of public cloud solutions (e.g., the likes of AWS, Microsoft Azure, etc.), it would be common to see provisions whereby the service provider would warrant only to use “reasonable endeavours” to correct any non-compliance with specifications, and on the basis that if such non-compliances could not be readily resolved, then the sole remedy of the customer would be to terminate that aspect of the cloud service and receive a pro rata refund. A similar approval is often applied to alleged IP infringements.

  • Compliance with Laws

We have seen a considerable deviation in approach in this regard, depending on the nature of the cloud services (where bespoke modifications can be more readily accommodated). For private cloud services, where the service provider can commit to maintain compliance with laws, the key area of debate is instead centred on who has to monitor and interpret the new requirements, and thereafter bear the cost of any resulting changes. For public cloud services – and even for “private” cloud services, which are based on distinct instances of a particular product that the service provider wants to keep in line with its “core” product – the willingness of the service provider to commit to compliance may be limited to those laws that make specific reference to it as a service provider, or potentially to the laws of a particular sector or function on which the cloud services are particularly focused. The customer may then face a difficult challenge in that sector if specifying requirements proceed in a direction potentially at odds with the cloud solution it has commissioned.

As the customer will be dependent upon the cloud services provided to ensure that the relevant services are provided in such a way as to enable the customer to comply with its legal obligations, it is not surprising that the contract terms related to compliance with law and regulation are increasingly subject to negotiation (despite many cloud service providers initially arguing that all they offered was “a service” and that it would then be for the client to do the mapping against its relevant obligations).

  • GDPR/data protection compliance

Many of the cloud services standard terms we have seen are very carefully crafted by the service provider so as is to emphasise their role as data processor rather than controller, and to thus emphasise the fact that the majority of statutory obligations remain with the client (at least until the advent of GDPR). However, many customers are wise to this and will at least push back to force the service provider to take on the relevant security obligations vis-a-vis appropriate technical and organisational measures to safeguard data from unauthorised access or alteration.

Service Providers can point out that in this regard, that they will not necessarily know what data the customer is asking them to host or process via the relevant cloud service, and so they are in no position to judge what measures should be taken. Indeed, it is possible that the advert of GDPR may add a new twist in this regard, with service providers instead asking the customer to warrant that the security arrangements are adequate for the customer’s purposes, and to indemnify the service provider against any future claims if they are ruled not to be.

With data being so central to cloud based services, data protection-related provisions receive a significant degree of attention when it comes to negotiating the associated contract terms.

  • Decommissioning and Disposal Costs

However, the reality is that the pace of decommissioning and disposal was likely to have been relatively steady in the past (and indeed many organisations will have delayed decommissioning and “sweated their assets” for longer than might be ideal). If, therefore. there is to be a “spike” in decommissioning as a supplier implements a cloud solution instead as part of a more root and branch transformation programme, the costs associated with that will have to be carefully considered, and budgeted for accordingly. For example, might the supplier incur the costs initially, but on the basis of amortising them across the lifetime of the contract thereafter to mitigate against the customer’s cashflow hit?

Even deals thought to be “private” cloud-based there may still be elements of this requirement. For example, if a service provider is servicing multiple clients from a single datacentre, then any changes to such datacentre’s generic infrastructure or networks would need to be adhered to by all of the relevant customers.

In the past, a customer organisation would have had to deal with the costs of decommissioning and disposing of redundant hardware. In the context of a cloud transformation programme, therefore, it may be tempting to leave the associated effort and cost of this out of the equation, when calculating the business case.

  • Supplier Mandated Changes

On some larger deals, we have also seen SaaS providers willing to contractually commit to maintain set functionality for minimum periods, and/or to continue with an agreed upgrade/development path.

For truly public cloud services, it is usually the case that the contract terms reserve for the service provider the right to make changes to the service descriptions. Where the services are delivered communally to multiple clients and need to evolve to remain competitive, this makes eminent sense. However, we have increasingly seen service providers willing to modify/mitigate this approach, e.g., by committing to only improve the services offered, or at least to not make any “material” reductions in what has gone before, and/or to offer termination rights for the customer if it does not agree with the changes being made.

  • Suspension and Termination Rights

In many forms of standard cloud services deals promulgated by service providers, we have seen both termination and suspension rights drafted so as to set the bar at a very low level; so much so that in some cases, even the slightest mis-step may lead to a loss of service for the customer. However, as the size and reach of cloud service offerings have expanded, customers have increasingly focused on the breadth of such rights and sought to narrow them. It has become the norm in outsourcing contracts for the service provider’s sole right of termination to be non‑payment of fees, and it could be argued that the customer’s degree of reliance upon a cloud-based service may actually be greater than that of a “traditionally” outsourced one (where there may be assets, contracts and staff who can be more readily transferred back to the customer or a replacement supplier).

  • Liability Exclusions

Liability provisions have been another key area of the contract where standard cloud services seem to have dialled back the extent of risk that they are willing to assume. Aside from attaching the liability limits to the fees paid for only those services that proved defective (rather than the charges as a whole), we have seen blanket exclusions of data related losses, applications of the cap to (traditionally unlimited) IP and confidentiality related claims, and even exclusions of losses relating to the costs of procuring replacement services. A typical justification for this approach from a public cloud service provider might be that it would not be able to take on more significant degrees of liability if something went “wrong” with its solution. In such a case, it is likely that such a malfunction would affect multiple customers, if not all. Accordingly, the provider might then being exposed to multiple related claims, which, by reason of a single default, could ultimately lead to bankruptcy.

  • Prime Contractor/Supply Chain Challenges

We have seen a number of deals which previously may have been approached as outsource-style contracts with a service-orientated prime contractor, who could, in turn then subcontract or sublicense elements of the overall solution. However, many SaaS providers are either reluctant to accept the flow down of contract risk from the prime contract, or seek to position themselves as the first point of contact with the customer. The risk scenario for the former option is problematic for the prime contractor, who may then feel trapped between the contract expectations of the customer and what it can pass down to the cloud service provider (e.g., in terms of warranty or service level commitments, liability caps, etc.). The second scenario may pose a similar challenge for the customer, who may be unpleasantly surprise when comparing the proposed SaaS contract terms against those typically used for achieving similar, non-cloud-based services. For example, we recently advised a major client who was considering a cloud services deal potentially valued in the hundreds of millions of pounds. This client was shocked to find potential suppliers refused to respond to their draft contract terms. Instead, the client was directed to a web link containing the supplier’s standard cloud services terms, which were available to the world at large and where, for example, the sole remedy for the customer in the event that the SaaS solution did not work (after the customer would have spent tens of millions of pounds on implementation, etc.) would be to get a refund of pre-paid fees.

  • Audit Rights

In a private cloud environment which is dedicated to a single client, this is easy to accommodate. However, the moment one ventures into environments used to support multiple clients, difficulties can emerge. The service provider would then want to ensure that any audit undertaken by Client A does not impact upon the services it provides to Clients B, C and D from the service data centre. For public cloud services, it is unlikely that any customer-specific audit right will be granted at all. However, customers can still expect the service provider to undertake regular generic audits using an independent third party, such that the resulting audit report can then be made available to all customers. We have seen this approach taken on occasion, although many service providers are still resistant to it.The business benefits of cloud solutions are so manifest and substantial that there is ever greater momentum in favour of their implementation, and for more and more substantial and business critical functions. At the same time, however, we are also seeing a rapid development of the contracting models for such solutions, particularly for private and/or hybrid cloud models, and we can expect this state of flux to persist for some time to come.

Conclusion

This is sensible and reasonable. However, recent regulatory guidance in the UK (e.g., the FCA’s FG 16/5 note on Cloud Contracts) suggested that “unrestricted” audit access might be required, and it remains to be seen how literally this requirement/guidance will be interpreted.

An organisation that entrusts its core functions and data to the cloud will be understandably concerned to ensure that all of the contractually promised safeguards are being implemented. Having an effective audit right is key to accomplishing this.

Posted in New Privacy Laws Privacy and Data Security

Congress Rolls Back FCC Broadband Privacy Rules: What Does It Mean?

Written by Sydney White and Jim Halpert

This week the US House of Representatives passed a Congressional Review Act (CRA) resolution of disapproval of the US Federal Communications Commission (FCC) broadband privacy rules that were approved by the FCC in a straight partisan vote at the end of the Obama Administration, but have not yet taken effect.  The Senate passed an identical resolution last week.  President Trump has signaled that he will sign the resolution, which means that the FCC is prohibited by the CRA from imposing “substantially similar” privacy regulations on broadband ISPs in the future.

The broadband privacy rules would have imposed an opt-in consent requirement for use of web browsing activity by ISPs for marketing or advertising and a 7 day breach notification deadline.   They would have applied only to ISPs and not to any other businesses in the Internet ecosystem.   Interestingly, the rules were opposed not only by ISPs but also by a wide range of other Internet and advertising companies, and were subject to criticism for imposing confusing disparate regulation on select companies based upon siloed regulatory classifications.  As a result of the CRA resolution, privacy regulation of broadband ISPS, which was to be more demanding than regulation of other Internet companies, will become similar again.

Although the current FCC Chairman Ajit Pai opposes the broadband privacy rules and could have chosen to forebear from enforcing them or could have amended the rules through the rulemaking process, a future FCC could have reversed that decision. Congressional passage of the CRA resolution provides long term certainty.

Although selective, more aggressive privacy requirements for ISPs will be foreclosed, the CRA essentially puts the US privacy framework back where it was before November 2016, and does not create a regulatory loophole for ISPs to sell customer information, as some advocates have charged. The FCC will continue to have the authority over the privacy of telecomm usage information as well as to enforce unreasonable broadband privacy and security practices.

In January, more than 15 ISPs announced that they would adhere to a voluntary set of privacy and data security principles that are consistent with the more flexible US Federal Trade Commission (FTC) framework, which applies to the rest of the Internet.  The principles include specific policies on transparency, consumer choice, security and data breach notification.

  • The transparency principle confirms that ISPs will continue to provide customers with comprehensive, accurate, and continuously available notice of collection, use, and sharing of customer information.
  • Under the choice principle, ISPs will continue to give customers choice over use or disclosure of their data consistent with the FTC’s framework.  Choice will vary depending upon the sensitivity of the information.  Sharing of sensitive information will require opt-in choice, non-sensitive information will require opt-out choice, and uses such as fraud prevention, product development, market research, network management and security, compliance with law, and marketing by the ISP will be subject to implied consent.
  • Under the data security principle, ISPs will continue to protect customer information collected by the ISP using reasonable security measures taking into account the nature of the ISPs activities, sensitivity of data, size of the ISP, and technical feasibility.
  • The data breach principle provides that ISPs will continue to notify customers of data breaches where there is unauthorized acquisition of customers’ sensitive personal information.

State Attorneys General can enforce these ISP privacy and security commitments in addition to existing state privacy, data security, and data breach laws that have protected and will continue to protect consumers.

Both FCC and FTC privacy enforcement authority over ISPs could change if the FCC or Congress overturns the FCC’s reclassification under the Open Internet Order of broadband providers as common carriers under Title II of the Communications Act. Congressional or FCC action to overturn that order would restore FTC authority over ISP privacy and security practices.  While both Chairman Pai and leaders of the Congressional committees with jurisdiction over the FCC and FTC are on record as supporting this change, this reversal of the underpinnings of broadband regulation is a longer term and more complicated policy objective.

One immediate effect of the CRA is likely to be legislative activity in several states to impose opt-in consent requirements at the state level. Already, legislators have added a written opt-in consent requirement for information collection by ISPs to Minnesota’s budget bill. The long term effect is likely to be to focus more attention on giving the US FTC clearer authority over privacy and security practices of businesses in many sectors in order to create clear and uniform privacy and security requirements across those sectors.

Posted in Cybersecurity Privacy and Data Security

New York AG Announces Record Year for Data Breaches in New York – and Updates Guidance on Reasonable Security Measures

Written by Michelle Anderson and Anne Kierig

New York Attorney General Eric Schneiderman announced that his office received a record number (1,300) of data breach notices in 2016. In the press release, Attorney General Schneiderman also provided a list of recommendations for how organizations can help protect sensitive personal data—a list that could be used as a benchmark against which the Attorney General’s office could evaluate whether a company has implemented reasonable security measures.

Many of the recommendations overlap with those made by other regulators (e.g., minimizing data collection practices is in the FTC’s Start with Security: A Guide for Business), but they reiterate that the New York Attorney General considers both encryption and offering post-breach services like credit monitoring to be more of an expectation than an option. They also highlight the importance of having a written information security policy, rather than undocumented procedures. The Attorney General’s recommendations update recommendations made in a 2014 report titled Information Exposed: Historical Examination of Data Security in New York State and are as follows:

  • Understand where your business stands by understanding the types of information your business has collected and needs, how long it is stored, and what steps have been taken to secure it. Data mapping would be a ready way to meet this recommendation.
  • Identify and minimize data collection practices by collecting only the information that you need, storing it only for the minimum time necessary, and using data minimization tactics when possible (e.g., don’t store credit card expiration dates with credit card numbers).
  • Create an information security plan that includes encryption and other technical standards, as well as training, awareness, and “detailed procedural steps in the event of data breaches.” This recommendation reiterates a recommendation from the 2014 report, in which the Attorney General said that effective technical safeguards include “[r]equir[ing] encryption of all stored sensitive personal information—including on databases, hard drives, laptops, and portable devices.”
  • Implement an information security plan and conduct regular reviews to ensure that the plan aligns with ever-changing best practices.
  • Take immediate action in the event of a breach by investigating immediately and thoroughly and notifying consumers, law enforcement, regulators, credit bureaus, and other businesses as required. This is the only new recommendation from the 2014 report, which mentioned the importance of immediate breach response in the context of implementing an information security plan. Now, however, it’s a separate recommendation.
  • Offer mitigation products in the event of a breach, including credit monitoring.

The announcement also revealed that the number of data breaches reported to the New York Attorney General’s office in 2016 represented a 60% increase over prior years. It reported that the most common causes of data breaches were external (i.e., hacking) and employee negligence (consisting of inadvertent exposure of records, insider wrongdoing, and the loss of a device or media). These causes accounted for, respectively, 40% and 37% of the reported breaches, showing a rise in employee negligence as a breach source. The information exposed consisted overwhelmingly of Social Security numbers (46%) and financial account information (35%).

This announcement also comes on the heels of final cybersecurity rules for the financial sector from the New York Department of Financial Services (NYDFS). The NYDFS requirements went into effect on March 1, 2017, and are designed to keep both “nonpublic information” and “information systems” secure. More information about these requirements can be found in DLA Piper’s Cybersecurity Law Alert NYDFS announces final cybersecurity rules for financial services sector: key takeaways.

 

LexBlog