Navigating NY DFS Part 500.16: Incident Response Plan

Disclaimer: The following information is generalized, not necessarily up-to-date with current laws and/or rulings, and should not be relied upon for legal purposes. The following information is not intended to be legal advice; individuals should consult an attorney in their respective jurisdiction(s) to obtain legal advice tailored to their specific needs and applicable law(s).

* Italicized terms used throughout this article refer to terms defined in 23 NYCRR § 500 (NY DFS 500). A copy of 23 NYCRR § 500 can be found here.

Section 500.16: Incident Response Plan (Deadline: August 28, 2017)

An incident response plan, generally, refers to how the organization responds to potential cybersecurity incidents. Incident response plans generally include multiple phases, usually beginning with the detection of a cybersecurity incident and usually ending with a review of how to improve, if necessary, the organization’s response to the incident.

Section 500.16 requires that an incident response plan be written and designed to promptly respond to, and recover from, any cybersecurity event materially affecting the confidentiality, integrity, or availability of the covered entity’s information systems or the continuing functionality of any aspect of the covered entity’s business or operations. The incident response plan shall address the following:

  1. the internal processes for responding to a cybersecurity event;
  2. the goals of the incident response plan;
  3. the definition of clear roles, responsibilities, and levels of decision-making authority;
  4. external and internal communications and information sharing;
  5. identification of requirements for the remediation of any identified weaknesses in information systems and associated controls;
  6. documentation and reporting regarding cybersecurity events and related incident response activities; and
  7. the evaluation and revision as necessary of the incident response plan following a cybersecurity event.

Depending on how large or complex an organization is, this procedure may be especially long. I believe the simplest way to write this procedure is to gather the organization’s cybersecurity personnel and imagine walking through a cybersecurity event. Ask questions such as:

  • “How will the event be detected?”
  • “Who will be contacted/notified at phase n? Who will do the contacting?”
  • “What is the priority at phase n?”

This procedure is generally meant to be very specific. It should be written in such a way that an individual may reference it and know what they are supposed to be doing, who they are supposed to be contacting, and the information necessary to pass along to the contact.