As we have noted previously on the new DFS cybersecurity regulations, 23 N.Y.C.R.R. Part 500, the regulatory process is—by definition—vastly more swift and adaptable than the legislative process. What may get bogged down in legislative committee for months or years can be hammered out in a matter of days in the administrative state.

The sheer size of the recent Equifax breach—affecting nearly half of all Americans and potentially more than half of those over 18—is staggering.  It is the nature of the breach, however, and the type of information taken, that gives the greatest pause.

For more than two years now, we’ve spoken and presented to various groups on New York’s Paid Family Leave Benefits Law (PFL), dozens, and dozens, and dozens of times. Like clockwork, one of the curious attendees would always ask whether PFL benefit payments would be taxable and whether PFL employee contributions would be pre- or post-tax deductions. Each time, we’d be forced to answer something along the lines of, “we don’t know yet— reasonable minds can disagree, and we are waiting on promised guidance on this from the state.” Well, throw that old answer out; we now know! The answers are the seemingly incongruous “taxable” and “post-tax.”

On October 3, 2012, Nationwide Mutual Insurance Company and its wholly-owned subsidiary Allied Property & Casualty Insurance Company experienced a data breach when a hacker exploited a vulnerability on the companies’ web application hosting software. This hack resulted in the compromise of the personal information of 1.27 million consumers, including social security numbers, driver’s license numbers, credit scoring information, and other data used to provide insurance quotes.

Few things have upended the world of cybersecurity regulation in the United States recently more than the new cybersecurity regulations issued by the New York State Department of Financial Services (“DFS”) in March of this year. Found in 23 N.Y.C.R.R. Part 500, these new regulations are sweeping in scope and reach far beyond the financial services sector in New York, affecting entities that support that sector as well as a number of other entities that may not have thought of themselves as governed, even in part, by DFS.

The original proposed version of Part 500 was very prescriptive, mandating specific security controls such as multi-factor authentication and encryption both at rest and in transit for all entities covered by the regulations (defined as “Covered Entities”), regardless of size, the risk they face, or the particular circumstances of their operations. This marked a break with the prevailing models for cybersecurity regulation in the United States, such as HIPAA and the Safeguards Rule under the Gramm-Leach-Bliley Act, which provide more risk-adjusted approaches to security. Public comment on the prescriptive nature of the original, proposed version of Part 500 was negative, and DFS revised the regulations to adopt a more risk-adjusted approach.

Central to this approach is the Risk Assessment required under the new regulations. This Risk Assessment is key to determining what level of security and what specific security controls are applicable to a particular Covered Entity, including multi-factor authentication, encryption, as well as the scope of penetration testing and vulnerability assessments. Recent guidance from DFS concerning the new regulations also shows how DFS is relying on the Risk Assessment as a guidepost in areas not specifically, or perhaps insufficiently, addressed in Part 500.

Case in point: reporting obligations in relation to unsuccessful Cybersecurity Events, as defined under the new regulations. “Cybersecurity Event” is one of the most controversial terms in the new regulations, encompassing “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.” See 23 N.Y.C.R.R. § 500.01(d).

This definition conceivably encompasses every firewall deny and every activation of the Covered Entity’s Intrusion Detection and Intrusion Prevention Systems (IDS/IPS), which—even for a small Covered Entity—could total over a million potential Cybersecurity Events per month, with many of the potential Events being false positives.

The problem with this deafening background noise of potential Cybersecurity Events is the fact that, under the new regulations, a Covered Entity has a duty to report a Cybersecurity Event, even an unsuccessful Cybersecurity Event, if the Event has a “reasonable likelihood of materially harming any material part of the normal operations” of the Covered Entity. See 23 N.Y.C.R.R. § 500.17. Once this test is met, a Covered Entity has 72 hours to report the Event to DFS.

This issue of reporting an unsuccessful Cybersecurity Event that meets this test is one of the most contentious and concerning aspects of the new regulations, with the 72-hour reporting window being far and away the most aggressive reporting window that many Covered Entities must deal with. Recent guidance from DFS, however, shows how the defined Risk Assessment provides a Covered Entity with a modicum of discretion in making the call as to whether to report.

Found here, DFS addressed the issue of reporting unsuccessful Cybersecurity Events and stated that:

• 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.
  DFS provides two important guidelines here: (i) that it anticipates that most unsuccessful attacks will not be reportable; and (ii) that the Risk Assessment is key in determining what unsuccessful attacks might be reportable.

This only underscores the key role of the Risk Assessment in developing a compliance program for the new regulations. If a Covered Entity fails to address the issue of when an unsuccessful attack might be reportable in its Risk Assessment, it loses the opportunity to appropriately tailor its reporting obligations to DFS. This, in turn, will lead to confusion and disruption as the Covered Entity scrambles to determine whether each unsuccessful attack it experiences might be reportable, effectively reaching a decision on this crucial issue ad hoc for each such attack.

If a Covered Entity wishes to reduce the burden and potential pitfalls of complying with the 72-hour reporting window, it is best served by conducting its reporting analysis as part of its Risk Assessment, rather than after the fact in the heat and confusion of incident response.

In this regard, a Covered Entity that is also covered by one of the other risk-adjusted regulatory schemes (such as HIPAA or Gramm-Leach-Bliley) should take care not to re-create the Risk Assessment wheel, by ignoring its HIPAA Risk Assessment, for example, when conducting its DFS Risk Assessment. The only thing potentially worse than an incomplete or less-than-comprehensive DFS Risk Assessment is one that conflicts with another regulatory Risk Assessment that a Covered Entity may have conducted. When a Covered Entity’s best efforts at protecting against a cyber-attack fail—which they almost certainly will, from time to time—hindsight is often 20/20 and will, for example, call into question why a risk labeled as “high” in one assessment is not given the same treatment in another.

Hence, Covered Entities beware: there is a risk (as well as a potential reward) in conducting your DFS Risk Assessment.