The New York Department of Financial Services’ (“DFS”) recent enactment of “Cybersecurity Requirements for Financial Services Companies” is the first of its kind. In an effort to protect DFS regulated entities (and their customers) from “the ever-growing threat posed to information and financial systems by nation-states, terrorist organizations and independent criminal actors, DFS has enacted certain minimum standards designed “to promote the protection of customer information as well as the information technology systems of regulated entities.” See 23 NYCRR 500.00.
So, what does this mean for your organization?
Who is Covered?
A Covered Entity means any organization operating under or required to operate under a license, registration, charter, certificate, permit, accreditation or similar authorization under New York’s Banking Law, the Insurance Law or the Financial Services Law. See 23 NYCRR 500.01(c).
This definition isn’t limited to banks and insurance companies, but also include check cashers, money transmitters, finance companies, a variety of lenders and brokers, holding companies, and investment companies to name a few. If you want to get into the nitty gritty, you can do so on DFS’ website.
The Cybersecurity regulations do provide for certain exceptions to certain aspects of the regulation depending on the size of your organization. And because the definition of a covered entity is so broad, it is recommended to consult with legal counsel to determine whether, based on your organization’s operation, you are (or should be) covered, and whether any exemptions may apply.
It is also worth noting that even if your organization isn’t directly covered under the definition of a Covered Entity, you may be considered a Third Party Service Provider, as defined by the regulation, if you “maintain, process, or are otherwise permitted access to Nonpublic Information” through your provision of services to a Covered Entity. 23 NYCRR 500.01(n).
In short, businesses providing services to Covered Entities, will ultimately feel the effects of the new Cybersecurity regulations. Your customers and your business partners will likely demand it, so its best to prepare your business ahead of time.
What is Required and When?
At a high level, and most immediately, the regulation requires that all Covered Entities comply with the following by August 28, 2017:
— Conduct a documented risk assessment
— Establish a risk-based cybersecurity program
— Adopt a written cybersecurity policy
— Designate a qualified CISO and have qualified cybersecurity personnel available
— Implement written third-party cyber risk policies
— Establish a written incident response plan
Other requirements (see below) have transitional periods of one year, 18 months, and two years from the effective date of the Regulation.
Covered Entities must also submit an annual certification of compliance with the Regulation for the prior year to the NYDFS, beginning on or before February 15, 2018. See §500.17(b).
Additional key compliance dates:
— March 1, 2018 – One year transitional period ends. Covered Entities are required to be in compliance with the requirements of sections 500.04(b) (the CISO report), 500.05 (Penetration and Vulnerability Testing), 500.09 (Periodic Risk Assessment Requirements), 500.12 (Multi-Factor Authentication) and 500.14(b)(Cybersecurity Awareness Training for all personnel) of 23 NYCRR Part 500.
— September 3, 2018 – Eighteen month transitional period ends. Covered Entities are required to be in compliance with the requirements of sections 500.06 (Audit Trails), 500.08 (Application Security), 500.13 (Retention Schedule), 500.14(a) (Policies and Procedures to Monitor Authorized Users) and 500.15 (Encryption) of 23 NYCRR Part 500.
— March 1, 2019 – Two year transitional period ends. Covered Entities are required to be in compliance with the requirements of 23 NYCRR 500.11 (Third Party Service Provider Security Policy).
Things to Pay Close Attention To
During a recent panel discussion held at Currency on July 11th, I was asked what aspects of the new regulations I found to be most “surprising.” There were two that immediately came to mind. And while certainly acknowledging that the regulations set forth are indeed, well intentioned, the breadth and scope of the regulations are broad. Certainly broader than any other data privacy or breach notification statute on the books in the 48 jurisdictions that have enacted them. So what aspects go beyond what everyone is used to. Here are two:
- The Definition of Nonpublic Information
In nearly every other context, privacy and data breach notification laws have focused on the security of personally identifiable information (“PII”) and/or personal health information (“PHI”). While every jurisdiction may contain a slightly different definition of what constitutes PII, PII typically includes the type of data you’d suspect – drivers licenses numbers, social security numbers, dates of birth, passwords and security codes, and the like. DFS includes all that, and some more.
Section 500.01(g) also includes “business related information of a Covered Entity” which, if disclosed, accessed, or used improperly, would cause a “material adverse impact to the business, operations, or security of a Covered Entity.” That covers a lot of data. The definition could potentially include: Nonpublic financial information, trade secrets, strategy, competitive pricing information, you name it. This expansive definition is important, given the reporting requirements discussed below.
- Reporting Requirements of “Cybersecurity Events” & What a “Cybersecurity Event” Actually Is
Section 500.17(a) covers the reporting requirements expected of Covered Entities. Beginning August 28, 2017, Covered Entities must notify the superintendent of NYDFS of any Cybersecurity Events “as promptly as possible but in no event later than 72 hours from a determination that a Cybersecurity Event has occurred” that either (1) impacts the Covered Entity “of which notice is required to be provided to any government body, self-regulatory agency or any other supervisory body”; or (2) has “a reasonable likelihood of materially harming any material part of the normal operation(s) of the Covered Entity.” §500.17(a).
For notification purposes, a “Cybersecurity Event” means “any act or attempt, successful or unsuccessful, to gain unauthorized access to, disrupt or misuse an Information System or information stored on such Information System.” §500.01(d). However, according to the FAQs posted on the NYDFS website:
“The Department recognizes that Covered Entities are regularly subject to many attempts to gain unauthorized access to, disrupt or misuse Information Systems and the information stored on them and that many of these attempts are thwarted by the Covered Entities’ cybersecurity programs. The Department anticipates that most unsuccessful attacks will not be reportable, but seeks the reporting of those unsuccessful attacks that, in the considered judgment of the Covered Entity, are sufficiently serious to raise a concern. For example, notice to the Department under 23 NYCRR Section 500.17(a)(2) would generally not be required if, consistent with its Risk Assessment, a Covered Entity makes a good faith judgment that the unsuccessful attack was of a routine nature. … The Department trusts that Covered Entities will exercise appropriate judgment as to which unsuccessful attacks must be reported and does not intend to penalize Covered Entities for the exercise of honest, good faith judgment.”
This section of the regulation must also be read in combination with other laws and regulations that apply to consumer privacy. Thus, under 23 NYCRR 500.17(a)(1), a Covered Entity must give notice to DFS of any Cybersecurity Event “of which notice is required to be provided to any government body, self-regulatory agency or any other supervisory body,” which includes many Cybersecurity Events that involve consumer harm, whether actual or potential.
The requirement to report “unsuccessful” cybersecurity events is new. There is little guidance as to how organizations ought to categorize unsuccessful attempts as having the potential to inflict materially harm or are “sufficiently serious” enough to report. Whatever thresholds are ultimately used by the organization, it is important that you work with both counsel as well as security professionals to ensure uniformity in your reporting and ensuring any decision not to report is both defensible and reasonable.
Thought leaders agree that the DFS regulations are certainly an indication of what’s to come. As the regulations come into effect and application, it will be important to watch how DFS manages the huge influx of data it has asked to receive, what DFS ultimately does with that data, and what sort of auditing and enforcement will result. These regulations ought to be taken seriously and organizations should be thoughtful about the manner in which they are implemented. Don’t write a policy if your organization won’t actually follow the practice. Be consistent. Be thorough. And be ready by August 28th!
About the Author:
Dara has represented clients in multiple regulatory and litigation areas, including the FDCPA, the FCRA, the TCPA, securities laws, state unfair and deceptive trade practices laws, state consumer protection laws, state licensing requirements, and state bank regulatory advocacy. Dara also counsels her clients with respect to their policies and procedures, design of compliance management systems and implementing best practices in evolving areas of financial services. Dara has represented clients in both criminal and civil matters before state Attorneys General, the CFPB, FTC, SEC, and other state and federal regulators. She also counsels clients in navigating state and federal requirements pertaining to data privacy, data breach issues (and related ancillary litigation), as well as the preservation and production of electronically stored information (ESI).