Effective Date Supersedes N/A Issuing Authority Vice President, Information Technology and Chief Information Officer Responsible Officer Vice President, Information Technology and Chief Information Officer
Appendix A: Breach of GDPR Data
Appendix B: PHI/EPHI Breach Definitions
Appendix C: Notification in the case of PHI/EPHI exposure
An information technology (IT) security incident is an event involving an IT resource at New York University (NYU) that has the potential of having an adverse effect on the confidentiality, integrity, or availability of that resource or connected resources. Resources include individual computers, servers, storage devices and media, and mobile devices, as well as the information, messages, files, and/or data stored on them. Prompt detection and appropriate handling of these security incidents is necessary to protect New York University's information assets and to preserve the privacy and confidentiality of personal data.
The purpose of this IT Security Information Breach Notification Policy is to provide general guidance to NYU to enable quick and efficient recovery from security incidents; respond in a systematic manner to incidents and carry out the steps necessary to handle an incident and minimize disruption to critical computing services or loss or theft of sensitive or mission critical information.
The sections below describe: 1) Who to notify upon discovery of an incident; 2) procedures for handling and recovering from an incident in a manner appropriate to the type of security incident; and 3) how to establish a reporting format and evidence retention procedure. This document provides an overview of the process. Detailed technical procedures can be found in NYU IT/Office of Information Security (OIS) internal documentation, including the Data Breach Investigation template. Any questions about this Policy should be directed to the NYU IT Office of Information Security ("NYU IT OIS"), email@example.com.
This IT Security Information Breach Notification Policy also applies to Breaches concerning all NYU's Health Insurance Portability and Accountability Act (HIPAA) Covered Components and Support Components, and to all of NYU's Business Associates included under HIPAA. HIPAA, the Health Information Technology for Economic and Clinical Health (HITECH) Act, and their implementing regulations (e.g., the Omnibus Rule) expand the privacy and security aspects of HIPAA. The NYU School of Medicine follows HIPAA-related policies and procedures created specifically for its environment; School of Medicine compliance with HIPAA is coordinated through Langone Medical Center.
One of the most significant HIPAA expansions is the requirement that Covered Entities (i.e., the individual NYU Covered Components or Support Components) notify individuals when there is a Breach of unsecured PHI. In addition, Business Associates and their subcontractors are directly liable for compliance and must provide proof of their efforts to prevent Breaches. The Breach notification obligation also requires that Covered Entities provide notice of the Breach to the Secretary of the Department of Health and Human Services ("Secretary" and "HHS"), and in some instances, to the media. This document complements the Breach notification information included within the HIPAA Privacy Policies of the NYU College of Dentistry and the HIPAA Privacy Policies of the NYU Student Health Center. It sets forth NYU's process for determining if a Breach of protected health information (PHI) or electronic protected health information (EPHI) has occurred and sets forth the procedures for making the appropriate notifications. Definitions concerning PHI/EPHI potential Breaches are specified in Appendix B. See also Data Classification at NYU for further guidance (https://www.nyu.edu/about/policies-guidelines-compliance/policies-and-guidelines/data-classification.html).
In the event of a Breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, GDPR Data (“GDPR Breach”), NYU is legally required to assess the risks to data subjects and may be required to notify data protection authorities and affected data subjects.
“GDPR Data” includes any personal information that is transmitted, stored, or otherwise processed by NYU relating to an identified or identifiable natural person that is subject to the European Union (EU) General Data Protection Regulation (“GDPR”); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person. For further guidance as to which personal information is subject to the GDPR, please consult with NYU’s GDPR Data Protection Officer (the “DPO”).
In order to comply with the requirements of the GDPR, it is critical that all of the steps outlined in this Policy occur within seventy-two (72) hours of the first point at which an incident is discovered. In all cases, regardless of jurisdiction, the process must be completed as expeditiously as is reasonably feasible.
When a security incident is detected or reported, key first steps are to (1) contain the incident, (2) initiate an investigation of its scope and origins, and (3) decide if it qualifies as a Breach.
The flow-charts below are a visual depiction of the procedure described below in its most typical occurrence. This first chart covers the general incident response procedure followed by the incident handler:
If Restricted Data (including PHI/EPHI) or GDPR Data is present on the compromised system, the Critical Incident Response (CIR) is followed. The CIR is summarized below.
a. Incident Handler: This role is filled by IT security staff from the NYU IT Office of Information Security (OIS).
b. System Administrator: This role is filled by the technical staff responsible for deploying and maintaining the system at risk. Also referred to as a "first responder" in the context of this process.
c. System Owner: This role is filled by the staff member or management member who has responsibility for the business function performed by the system. The System Owner is not necessarily the person who paid for the system, but rather the person who has control over it.
d. Network Operations: This role is filled by the technical staff responsible for network infrastructure at the site housing the system at risk. At Washington Square, this is NYU IT TOS Network Engineering.
e. HIPAA Privacy Officer and HIPAA EPHI Security Officer: These roles are filled at each HIPAA Covered Component by designated individuals. At the University level, the Executive Vice President is the HIPAA Privacy Officer, and the Vice President, Information Technology and Chief Information Officer is the HIPAA EPHI Security Officer.
f. PCI Compliance Manager: This role is filled by the person responsible for overseeing NYU's PCI compliance program.
g. DPO: This role is filled by NYU's GDPR Data Protection Officer, who may be assisted by designated Data Protection Officers at each of NYU’s Global Sites in the EU.
The identification phase of incident response has as its goal the discovery of potential security incidents and the assembly of an incident response team that can effectively contain and mitigate the incident:
a. Identify a potential incident. The incident handler may do so through monitoring of security sensors. System owners or system administrators may do so by observing suspicious system behavior. Any member of the University community may identify a potential security incident though external complaint/notification, or other knowledge of accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, Restricted Data or GDPR Data.
b. Notify: Members of the University community that suspect an IT system or paper-based files have been subject to accidental or unlawful destruction, loss, or alteration, or unauthorized disclosure or access, must immediately report the situation to firstname.lastname@example.org. Once the incident handler is aware of a potential incident, s/he will alert local system administrators. If an incident is discovered by a member of the Covered Component or Support Component or by a Business Associate, the person should notify OIS and the relevant Covered Component's or Support Component's HIPAA EPHI Security Officer and HIPAA Privacy Officer immediately, and follow OIS' instructions on how to proceed. No one should interact with the system, unless approved by OIS.
c. Quarantine: The incident handler will quarantine compromised hosts at the time of notification unless they are on the Quarantine Whitelist. If they are on the Quarantine Whitelist, the incident handler will promptly reach out to the system administrator or system owner to create a plan to contain the incident. Note that the incident handler may notify on suspicious behavior when s/he is not confident of a compromise; in these cases they do not quarantine the host immediately, but wait 24-48 hours and quarantine only if the registered contact is unresponsive.
This phase also precedes CIR, and has the primary goal of confirming that the compromise is genuine and presents sufficient risk to engage the CIR process:
a. Classify: The CIR must be initiated if...
i. The system owner or system administrator indicates that the system is a high-criticality asset according to the Reference for Data and System Classification.
ii. OR the system owner or system administrator asserts that the system contains Restricted Data as defined by the Data Classification Table, or GDPR Data, including PHI/EPHI.
iii. OR someone of appropriate authority (for example, an NYU IT Associate Vice President or higher) with input from a cognizant NYU school or administrative officer determines that the system poses a unique risk that warrants investigation.
b. Verify: The CIR process should be initiated ONLY if...
i. The incident handler verifies that the triggering alert is not a false positive. The incident handler will double-check the triggering alert, and correlate it against other alerting systems when possible.
ii. AND the type of data or system at risk is verified to be of an appropriate classification, as determined above. The system owner or system administrator should provide a detailed description of the data at risk, including approximate numbers of unique data elements at risk, and the number, location, and type of files it is stored in.
The order of the steps above can vary from incident to incident, but for the CIR process to be initiated the criticality of the asset must be confirmed, and it must be confirmed that the triggering event is not a false positive. In cases where the CIR process is not required, the incident handler can resolve the case as follows:
a. Obtain a written (email in the OIS ticketing system (RT) is acceptable and preferred) statement from the system owner or system administrator documenting that the system has no Restricted Data or GDPR Data and is not a high-criticality asset.
b. Obtain a written statement from the system owner or system administrator that the system has been reinstalled or otherwise effectively remediated before quarantine is lifted.
c. Obtain a written statement that the access point has been disabled for incidents involving an unauthorized wireless access point.
The containment phase represents the beginning of the CIR workflow and has the following goals:
a. If the host cannot immediately be removed from the network, the incident handler will initiate a full-content network dump to monitor the attacker's activities and to determine whether interesting data is leaking during the investigation.
b. Eliminate attacker access: Whenever possible, this is done via the incident handler performing network quarantine at the time of detection AND by the system administrator unplugging the network cable. In rare cases, the incident handler may request that network operations staff implement a port-block to eliminate attacker access. In cases where the impact of system downtime is very high, the incident handler will work with system administrators to determine the level of attacker privilege and eliminate their access safely.
c. The incident handler will collect data from system administrators in order to quickly assess the scope of the incident, including:
i. Preliminary list of compromised systems
ii. Preliminary list of storage media that may contain evidence
iii. Preliminary attack timeline based on initially available evidence
d. Preserve forensic evidence:
i. System administrators will capture first responder data if the system is turned on. The incident handler will provide instructions for capturing this data to the individual performing that task.
ii. The incident handler will capture disk images for all media that are suspected of containing evidence, including external hard drives and flash drives. System administrators will deliver the system to OIS after the first responder data is captured; disk imaging and analysis will occur at OIS. The system owner should expect to have it returned within 5 business days.
iii. The incident handler will dump network flow data and other sensor data for the system.
iv. The incident handler will create an analysis plan to guide the next phase of the investigation.
This is the most time-sensitive and also the most contextually dependent phase of the investigation. The actions that need to be taken will depend on the uptime requirements of the compromised system, the suspected level of attacker privilege, the nature and quantity of data at risk, and the suspected profile of the attacker. The most important goals of this phase are to eliminate attacker access to the system(s) as quickly as possible and to preserve evidence for later analysis.
Additionally, this is the phase where the incident handler works most closely with system administrators and system owners. During this phase they are expected to take instruction from the incident handler and perform on-site activities such as attacker containment, gathering first response data, and delivering the system to OIS in cases where host-based analysis is required.
The analysis phase is where in-depth investigation of the available network-based and host-based evidence occurs. The primary goal of analysis is to establish whether there is reasonable belief that the attacker(s) successfully accessed Restricted Data or GDPR Data on the compromised system. Secondary goals are to generate an attack timeline and ascertain the attackers' actions. All analysis steps are primarily driven by the incident handler, who coordinates communications between other stakeholders, including system owners, system administrators, and relevant compliance officers. Questions that are relevant to making a determination about whether data was accessed without authorization include:
a. Suspicious Network Traffic: Is there any suspicious or unaccounted for network traffic that may indicate data exfiltration occurred?
b. Attacker Access to Data: Did attackers have privileges to access the data or was the data encrypted in a way that would have prevented reading?
c. Evidence that Data was Accessed: Are file access audit logs available or are file system mactimes intact that show whether the files have been accessed post-compromise?
d. Length of Compromise: How long was the host compromised and online?
e. Method of Attack: Was a human involved in executing the attack or was an automated "drive-by" attack suite employed? Did the tools found have capabilities useful in finding or exfiltrating data?
f. Attacker Profile: Is there any indication that the attackers were data-thieves or motivated by different goals?
In the case of a potential GDPR Breach, this analysis will include the University’s DPO. The analysis will include an evaluation of the likelihood of risk to data subjects, including, for example, risks related to identity theft or fraud, financial loss, damage to reputation, and discrimination. The analysis should include whether the data has been encrypted, coded, or protected through other technological controls from use by an unauthorized person. The process and facts considered in reaching a determination as to the likely risks to data subjects must be documented.
In the case of a potential Breach of PHI/EPHI, this analysis will include the HIPAA EPHI Security Officer and the Privacy Officer at the relevant Covered Component or Support Component in conjunction with OIS. They will conduct a risk assessment to determine the probability that the security or privacy of the PHI/EPHI has been compromised based on an evaluation of the elements above in addition to the following four factors:
a. the nature and extent of the PHI involved, including the types of identifiers and the likelihood of re-identification,
b. the unauthorized person who used the PHI or to whom the disclosure was made,
c. whether the PHI was actually acquired or viewed, and
d. the extent to which the risk to the PHI has been mitigated.
Using these factors, OIS will determine the degree of technical probability that the security or privacy of the PHI/EPHI has been compromised, but the final determination belongs to the affected HIPAA Covered Component or Support Component. In order to make this determination, the Privacy Officer at the affected HIPAA Covered Component or Support Component will document each impermissible use and disclosure and the risk assessment conducted for each. That HIPAA Privacy Officer will be responsible for conducting the risk assessment, documenting the results of the assessment and whether the impermissible use or disclosure poses a significant risk of financial, reputational or other harm to the individual whose PHI/EPHI was compromised.
Exceptions to the definition of a Breach of PHI/EPHI are:
a. Any unintentional acquisition, access, or use of protected health information by a workforce member or person acting under the authority of a Covered Entity or a Business Associate, if such acquisition, access, or use was made in good faith and within the course and scope of authority and does not result in further access, use or disclosure in a manner not permitted under 45 CFR 164.402.
b. Any inadvertent disclosure by a person who is otherwise authorized to access protected health information at a Covered Entity or Business Associate to another person authorized to access protected health information at the same Covered Entity or Business Associate, or organized health care arrangement in which the Covered Entity participates, and the information received as a result of such disclosure is not further accessed, used or disclosed in a manner not permitted under 45 CFR 164.402.
c. A disclosure of protected health information where a Covered Entity or Business Associate has a good faith belief that an unauthorized person to whom the disclosure was made would not reasonably have been able to retain such information.
If, during analysis, it appears probable that Restricted Data or GDPR Data has been exposed, the incident handler should consult with the Vice President for IT/CIO (i.e., the NYU HIPAA Security Officer) or other appropriate NYU IT executives to determine the appropriate University Officials to inform regarding the situation. Those individuals may include, but are not limited to: the Vice President for Public Affairs, the Vice President for Public Safety, the relevant Dean, the Office of General Counsel, the GDPR Data Protection Officer, and the NYU HIPAA Privacy Officer. In the case of payment card data, this will include the PCI Compliance Manager.
If the incident involves personally identifiable information, the Office of General Counsel should be consulted to determine if there are other federal, state, or international legal requirements that may apply to the incident.
At the conclusion of the analysis, but before the final report is written, a peer review should be requested of the other OIS technical staff. Then, the write-up of the notes should be completed, including conclusions, and processed source materials (e.g., grep-results, file-timelines, and filtered flow-records) should be archived. The peer review may result in some issues that must be addressed and some issues that may optionally be addressed. All recommendations should be resolved or acknowledged and deferred. The incident handler's role is to determine, from a technical perspective, whether there is a reasonable belief that Restricted Data or GDPR Data, including PHI/EPHI, was available to unauthorized persons. The determination of whether the circumstances warrant a Breach notification will be made jointly by the University Officials convened upon review of the results of the investigation, the technical opinion of OIS, and the advice of the Office of General Counsel.
The primary goal of the recovery phase is to restore the compromised host to its normal business function in a safe manner.
a. The system administrators will remediate the immediate compromise and restore the host to normal function. This is most often performed by reinstalling the compromised host; although if the investigation confirms that the attacker did not have root/administrator access other remediation plans may be effective.
b. The system administrators will make short-term system, application, and business process changes to prevent further compromise and reduce operating risk.
The final report serves two main purposes. First, a recommendation is made to the Office of General Counsel and relevant compliance officers as to whether the incident handler and the responsible officials feel there is a reasonable belief that Restricted Data (including PHI/EPHI), or GDPR Data was subject to accidental or unlawful destruction, loss, or alteration, or unauthorized disclosure or access, and the degree of probability of risks to data subjects or that the security or privacy of any PHI/EPHI has been compromised. The report must be made in sufficient time to allow notification, if appropriate, within any legally-mandated time period. As noted, under the EU GDPR, notification to authorities must occur, wherever feasible, within 72 hours of discovery of a GDPR Breach. In the case of HIPAA/HITECH/Omnibus, that notification must occur within 60 days of discovering the Breach. Second, a series of mid-term and long-term recommendations are made to the owners of the compromised system/files, including responsible management, suggesting improvements in technology or business process that could reduce operating risk in the future.
a. The incident handler will draft the final report after the investigation is complete. Preliminary reports should be avoided whenever possible since working conclusions can change substantially through the course of an investigation.
b. After the draft report is completed, signoff on the content of the report should be obtained from OIS management. Technical personnel can offer comments now as well, but typically technical issues should be resolved by this stage. Again, a list of issues will be raised which should be resolved or acknowledged/deferred until OIS management accepts the report.
c. For critical incidents involving payment card data, the PCI Compliance Manager will receive a copy of the report and appropriate entities will be notified in the event that cardholder data is accessed without authorization. The PCI Compliance Manager will be responsible for all communication with the payment card brands and will be responsible for coordinating the activities mandated by the payment card brands with respect to the incident.
d. For incidents involving GDPR Data, the report will address each accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, GDPR Data. The notification procedure outlined in Appendix A will be followed.
e. For critical incidents involving PHI or EPHI, the report will include each impermissible use and disclosure and the risk assessment conducted for each. The notification procedure outlined in Appendix C will be followed.
f. If appropriate, given the analysis, the incident handler will obtain sign-off from the Office of General Counsel on the report.
g. The incident handler will schedule a meeting to deliver the final report to the system administrator, the system owner, as well as to responsible officials. Although the correct management contact will vary on a case-by-case basis, it should typically be Director-level or above. Do not distribute electronic copies of the report via email. If delivery in-person on-paper is not acceptable, deliver incident-reports via NYU Box.
h. The incident handler will ensure that the final report includes the details of the investigation and mid-term and long-term recommendations to improve the security posture of the organization and limit the risk of a similar incident occurring in the future.
a. The incident handler will archive the final report in case it is needed for reference in the future; reports must be retained for six (6) years.
b. Incident notes should be retained for six (6) months from the date that the report is issued. This includes the confluence investigation page, processed investigation materials like grepped file-timelines and filtered network-flows, etc.
c. Raw incident data should be retained for thirty (30) days from the date that the report is issued. This includes disk-images, unfiltered netflow-content, raw file-timelines, and other data that was collected but deemed not relevant to the investigation.
d. Request Tracker (RT) tickets from the OIS ticketing system related to the investigation should be retained for three (3) years.
a. Within 24 hours of the discovery of a GDPR Breach, the DPO, after consultation with the Office of General Counsel, will make a determination as to whether reporting to supervisory authorities and/or data subjects is required by law or is otherwise prudent. A determination from the DPO that notification is required and the authorization from an authorized member of management will initiate the external notification procedure. Notification to EU data protection authorities is required unless a determination is made that the Breach is unlikely to result in a risk to data subjects. If the Breach is likely to result in a high risk to data subjects, notification to data subjects is also required.
b. The DPO, after consultation with the Office of General Counsel, will determine the appropriate authorities to notify. Notification to authorities must: (i) describe the nature of the Breach including where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of Personal Information records concerned; (ii) communicate the name and contact details of the DPO or other contact point where more information can be obtained; (iii) describe the likely consequences of the Breach; and (iv) describe the measures taken or proposed to be taken by NYU to address the Breach, including, where appropriate, measures to mitigate its possible adverse effects.
c. External reporting to the EU GDPR supervisory authorities must be conducted within 72 hours of discovery of the security incident, wherever feasible. If any delay in reporting is necessary, the reasons for this delay must be documented. In all cases, external reporting must be conducted within 30 days.
d. The business process owner of the compromised system/files will compile the list of the specific individuals whose GDPR Data is reasonably believed to have been accessed and/or acquired by an unauthorized person. When identification of specific individuals cannot be made, all individuals who are likely to have been affected, such as all whose GDPR Data is stored in the files involved, should be notified. The process for determining inclusion in the notification group must be documented.
e. The DPO, after consulting with the Office of General Counsel, will determine the plan for notifying individuals affected by the Breach consistent with the following guidelines:
The method of notification –
The content of the notice –
The timing of notification –
The following definitions apply to all of NYU patient privacy and security policies and procedures.
Breach - means the acquisition, access, use, or disclosure of protected health information in a manner not permitted under 45 CFR 164.402 which compromises the security or privacy of the protected health information. The term 'Breach' excludes:
Apart from the exceptions as provided in the paragraphs above of this definition, an acquisition, access, use, or disclosure of protected health information in a manner not permitted under 45 CFR 164.402 is presumed to be a Breach unless the Covered Entity or Business Associate, as applicable, demonstrates that there is a low probability that the protected health information has been compromised based on a risk assessment of at least the following factors:
Business Associates - Business associates mean a person or organization that creates, receives, maintains, or transmits protected health information in any form or medium, including electronic media, in fulfilling certain functions or activities for a HIPAA-Covered Entity and that performs a function or activity involving the use or disclosure of protected health information for or on behalf of the Covered Entity. A person or organization who only assists in the performance of the function or activity is also a Business Associate. This includes a person or organization that receives PHI from the Covered Entity, and one who obtains PHI for the Covered Entity.
Critical Incident Response (CIR) - See “Overview of Workflow,” Section 2 above, for description.
Discovered Breach - A Breach is to be treated as discovered by a Covered Entity or a Business Associate if any person, other than the individual committing the Breach, that is an employee, officer or other agent of such entity or associate knows or should reasonably have known of the Breach. The time period for notification begins when the incident becomes known, not when it is determined that a Breach as defined by the rule has occurred.
Electronic Protected Health Information or EPHI - means all electronic protected health information that New York University creates, receives, maintains, or transmits that is transmitted by or maintained in electronic media. Protected health information stored, whether intentionally or not, in a photocopier, facsimile, and other devices is subject to the HIPAA Privacy and Security Rules.
HIPAA Breach Notification Regulations - means the interim final Breach notification regulations (Breach Notification for Unsecured Protected Health Information), issued in August 2009 by the Department of Health and Human Services (HHS), to implement section 13402 of the Health Information Technology for Economic and Clinical Health (HITECH) Act, part of the American Recovery and Reinvestment Act of 2009 (ARRA) that was enacted on February 17, 2009, by requiring HIPAA Covered Entities and their Business Associates to provide notification following a Breach of unsecured protected health information.
HIPAA Omnibus Rule - means the amendments to the HIPAA Security Regulations published in the Federal Register on January 25, 2013, entitled "Modifications to the HIPAA Privacy, Security, Enforcement, and Breach Notification Rules Under the Health Information Technology for Economic and Clinical Health Act and the Genetic Information Nondiscrimination Act; Other Modifications to the HIPAA Rules; Final Rule."
Protected Health Information or PHI - means individually identifiable health information, as defined in the Privacy Regulations promulgated pursuant to HIPAA, transmitted or maintained in any form or medium. PHI excludes (i) individually identifiable health information in education records covered by the Family Educational Rights and Privacy Act, as amended, 20 U.S.C. - 1232g, (ii) records described at 20 U.S.C. - 1232g(a)(4)(B)(iv), and (iii) employment records held by New York University in its role as employer.
Unsecured PHI - means PHI that is not rendered unusable, unreadable, or indecipherable to unauthorized persons through the use of a technology or methodology specified by the Secretary of HHS.
Additional Definitions - For additional definitions, refer to the HIPAA Privacy Standards, 45 CFR Parts 160.101 and 164.501, and to the NYU HIPAA Security Policies (www.nyu.edu/about/policies-guidelines-compliance/policies-and-guidelines/hipaa-policies.html).
There is a presumption of Breach unless the Covered Component or the Support Component or Business Associate demonstrates through a documented risk assessment that there is a low probability that the PHI/EPHI has been compromised. If it has been determined that PHI/EPHI has been exposed, and that such exposure has resulted in the probability that PHI/EPHI was compromised, those patients must be notified following the procedure below. It is the responsibility of Covered Component's or Support Component's compliance/privacy officer to make the final determination whether notification is required.
The Covered Component or Support Component or Business Associate should maintain documentation that all required notifications were made, or, alternatively, that notification was not required.
a. If the risk assessment determines that a Breach has occurred, the Component will provide written notice without unreasonable delay and in no event later than sixty (60) days from incident discovery, to the patient or:
i. If the patient is deceased, the next of kin or personal representative.
ii. If the patient is incapacitated/incompetent, the personal representative.
iii. If the patient is a minor, the parent or guardian.
b. Written notification will be in plain language at an appropriate reading level with clear syntax and language with no extraneous materials. Americans with Disabilities Act (ADA) and Limited English Proficiency (LEP) requirements must be met.
c. Written notification will be sent by first-class mail to the last known address of the patient or, if deceased, the next-of-kin, or if specified by the patient, by encrypted electronic mail.
d. Written notification will contain:
i. A brief description of what occurred with respect to the Breach, including, to the extent known, the date of the Breach and the date on which the Breach was discovered;
ii. A description of the types of unsecured PHI that were involved in the Breach;
iii. A description of the steps the affected individual should take in order to protect himself or herself from potential harm resulting from the Breach;
iv. A description of what the Component is doing to investigate and mitigate the Breach and to prevent future Breaches; and
v. Contact procedures for individuals to ask questions or learn additional information, which will include a toll-free telephone number, an email address, Web site or postal address.
e. In the case where there is insufficient or out-of-date contact information:
i. For less than ten (10) individuals, a substitute form of notice shall be provided such as a telephone call.
ii. In the case that there are ten (10) or more individuals for which there is insufficient or out of date contact information and contact information is not obtained, the Component will:
• Post a conspicuous notice for ninety (90) days on the homepage of its website that includes a toll-free number; or
• Provide notice in major print or broadcast media in the geographic area where a patient can learn whether or not their unsecured PHI is possibly included in the Breach. A toll-free number will be included in the notice.
f. If the Component determines the patient should be notified urgently of a Breach because of possible imminent misuse of unsecured PHI, the Component may, in addition to providing notice as outlined in steps b-d above, contact the patient by telephone or other means, as appropriate.
In the case where a single Breach event affects more than 500 individuals, notice shall be provided to prominent media outlets without unreasonable delay and in no event later than sixty (60) days from incident discovery. NYU will make any such media contact pursuant to its media communications policies and procedure.
a. Notice will be provided by the Component without unreasonable delay and in no case later than sixty (60) days from the incident discovery to the Secretary of the Department of Health and Human Services (Secretary) if a single Breach event affects 500 or more individuals.
b. If a Breach affects fewer than 500 individuals, the Component will maintain a log of those Breach occurrences in any given calendar year and notify the Secretary annually within 60 days of the end of the calendar year in which the Breach occurred.
If a law enforcement official notifies NYU that a required notification, notice or posting would impede a criminal investigation or cause damage to national security, the Component will:
a. If the statement is in writing and specifies the time for which a delay is required, delay notification, notice or posting for the specified time period;
b. If the statement is oral, document the statement, including the identity of the official making the statement, and delay the notification, notice or posting temporarily and no longer than 30 days from the date of the oral statement, unless a written statement is submitted within that time.
IT Security Incident Management Procedure
IT Security Information Breach Notification Procedure
|2.0||3/12/2012||Included PCI DSS information|
Breach Notification provisions
|4.0||2/26/2016||Changed from ITS to NYU IT; also general updates|
|4.1||10/03/2016||Changed title designation from Vice President, Information Technology and Chief Information Technology Officer to Vice President, Information Technology and Chief Information Officer; and unit designation from NYU IT Technology Security Services to NYU IT Office of Information Security|
|4.2||3/9/2017||Reformatted list styles|
|5.0||5/11/2018||Updated for European Union (EU) General Data Protection Regulation (GDPR); Appendix A: Breach of GDPR Data added|