New York University Skip to Content Skip to Search Skip to Navigation Skip to Sub Navigation

POLICY

IT Security Information Breach Notification Procedure

Table of Contents

  1. Introduction
  2. Overview of Workflow
  3. Overview of Roles
  4. Identification
    1. Identify
    2. Notify
    3. Quarantine
  5. Verification
    1. Classify
    2. Verify
  6. Containment
    1. Initiate Full-Content Network Dump
    2. Eliminate Attacker Access
    3. Assess Scope of Incident
    4. Preserve Forensic Evidence
  7. Analysis
    1. Suspicious Network Traffic
    2. Attacker Access to Data
    3. Evidence Data was Accessed
    4. Length of Compromise
    5. Method of Attack
    6. Attacker Profile
  8. Recovery
  9. Reporting
  10. Data Retention
  11. Revision History

Appendix A: PHI/EPHI Breach Definitions
Appendix B: Notification in the case of PHI/EPHI exposure

  1. Introduction

    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 technology assets.

    The purpose of this IT Security Information Breach Notification Procedure is to provide general guidance to NYU staff and supervisors who manage IT resources to enable quick and efficient recovery from security incidents; respond in a systematic manner to incidents and carry out all necessary steps to correctly handle an incident; prevent or minimize disruption of critical computing services; and minimize loss or theft of sensitive or mission critical information. The sections below describe: 1) how to notify the appropriate persons upon discovery of an incident; 2) how to handle and recover from an incident in a manner appropriate to the type of incident; 3) establish reporting format and evidence retention procedures. This document provides an overview of the process; detailed technical procedures can be found in ITS/Technology Security Services (TSS) internal documentation, including the Data Breach Investigation template. Any questions about this procedure should be directed to ITS Technology Security Services ("ITS TSS"), security@nyu.edu.

    This IT Security Information Breach Notification Procedure 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 A. See also Data Classification at NYU for further guidance (https://www.nyu.edu/about/policies-guidelines-compliance/policies-and-guidelines/data-classification.html).


  2. Overview of Workflow

    The flow-charts below are a visual depiction of the procedure described below 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) is present on the compromised system, the Critical Incident Response (CIR) is followed. The CIR is summarized below.

  3. Overview of Roles

    1. Incident Handler: This role is filled by IT security staff from ITS Technology Security Services (TSS).
    2. 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.
    3. 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.
    4. Network Operations: This role is filled the technical staff responsible for network infrastructure at the site housing the system at risk. At Washington Square, this is ITS COS Network Engineering.
    5. 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 for Health is the HIPAA Privacy Officer, and the Vice President for Information Technology and Chief IT Officer is the HIPAA EPHI Security Officer.
    6. PCI Compliance Manager: This role is filled by the person responsible for overseeing NYU's PCI compliance program.

  4. Identification

    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:

    1. 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 impermissible use or disclosure of Restricted Data.
    2. Notify: Members of the University community that suspect an IT system has been accessed without authorization must immediately report the situation to security@nyu.edu. 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 TSS and the relevant Covered Component's or Support Component's HIPAA EPHI Security Officer and HIPAA Privacy Officer immediately, and follow TSS' instructions on how to proceed. No one should interact with the system, unless approved by TSS.
    3. 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.

  5. Verification

    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:

    1. Classify: The CIR must be initiated if...
      1. The system owner or system administrator indicates that the system is a high-criticality asset according to the Reference for Data and System Classification.
      2. OR the system owner or system administrator asserts that the system contains Restricted Data as defined by the Data Classification Table, including PHI/EPHI.
      3. OR someone of appropriate authority (for example, an ITS 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.
    2. Verify: The CIR process should be initiated ONLY if...
      1. 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.
      2. 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:

    1. Obtain a written (email in the TSS ticketing system (RT) is acceptable and preferred) statement from the system owner or system administrator documenting that the system has no Restricted Data and is not a high-criticality asset.
    2. 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.
    3. For incidents involving an unauthorized wireless access point, obtain a written statement that the access point has been disabled.

  6. Containment

    The containment phase represents the beginning of the CIR workflow and has the following goals:

    1. 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.
    2. 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.
    3. The incident handler will collect data from system administrators in order to quickly assess the scope of the incident, including:
      1. Preliminary list of compromised systems
      2. Preliminary list of storage media that may contain evidence
      3. Preliminary attack timeline based on initially available evidence
    4. Preserve forensic evidence:
      1. 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.
      2. 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 TSS after the first responder data is captured; disk imaging and analysis will occur at TSS. The system owner should expect to have it returned within 5 business days.
      3. The incident handler will dump network flow data and other sensor data for the system.
      4. 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 TSS in cases where host-based analysis is required.


  7. Analysis

    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 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 which are relevant to making a determination about whether data was accessed without authorization include:

    1. Suspicious Network Traffic: Is there any suspicious or unaccounted for network traffic that may indicate data exfiltration occurred?
    2. 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?
    3. 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?
    4. Length of Compromise: How long was the host compromised and online?
    5. 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?
    6. Attacker Profile: Is there any indication that the attackers were data-thieves or motivated by different goals?

    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 TSS. 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:

    1. the nature and extent of the PHI involved, including the types of identifiers and the likelihood of re-identification,
    2. the unauthorized person who used the PHI or to whom the disclosure was made,
    3. whether the PHI was actually acquired or viewed, and
    4. the extent to which the risk to the PHI has been mitigated.

    Using these factors, TSS 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:

    1. 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.
    2. 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.
    3. 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 has been exposed, the incident handler should consult with the Vice President for IT and CITO or other appropriate ITS 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 Dean, and the Office of General Counsel. In the case of payment card data, this will include the PCI Compliance Manager.

    At the conclusion of the analysis, but before the final report is written, a peer review should be requested of the other TSS technical staff. Complete the write-up of the notes, including conclusions, and archive processed source materials (e.g., grep-results, file-timelines, and filtered flow-records). 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, 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 TSS, and the advice of the Office of General Counsel.


  8. Recovery

    The primary goal of the recovery phase is to restore the compromised host to its normal business function in a safe manner.

    1. 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.
    2. The system administrators will make short-term system, application, and business process changes to prevent further compromise and reduce operating risk.

  9. Reporting

    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 PHI/EPHI or other Restricted Data was disclosed impermissibly without authorization and the degree of probability that the security or privacy of the PHI/EPHI has been compromised. The report must be made in sufficient time to allow notification, if appropriate, within any legally-mandated time period. In the case of HIPAA/HITECH/Omnibus, that is 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, including responsible management, suggesting improvements in technology or business process that could reduce operating risk in the future.

    1. 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.
    2. After the draft report is completed, signoff on the content of the report should be obtained from TSS 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 TSS management accepts the report.
    3. 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.
    4. 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 B will be followed.
    5. If appropriate, given the analysis, the incident handler will obtain sign-off from the Office of General Counsel on the report.
    6. 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 Webspace.
    7. 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.

  10. Data Retention

    1. 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.
    2. 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.
    3. 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.
    4. Request Tracker (RT) tickets from the TSS ticketing system related to the investigation should be retained for three (3) years.

APPENDIX A: PHI/EPHI Breach Definitions

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:

  1. 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.
  2. 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.
  3. 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.

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:

  1. The nature and extent of the protected health information involved, including the types of identifiers and the likelihood of re-identification;
  2. The unauthorized person who used the protected health information or to whom the disclosure was made;
  3. Whether the protected health information was actually acquired or viewed; and
  4. The extent to which the risk to the protected health information has been mitigated.

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.

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 (https://www.nyu.edu/about/policies-guidelines-compliance/policies-and-guidelines/hipaa-policies.html).

APPENDIX B: Notification in the case of PHI/EPHI exposure

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.

  1. Patient Notification

    1. 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:
      1. If the patient is deceased, the next of kin or personal representative.
      2. If the patient is incapacitated/incompetent, the personal representative.
      3. If the patient is a minor, the parent or guardian.
    2. 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.
    3. 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.
    4. Written notification will contain:
      1. 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;
      2. A description of the types of unsecured PHI that were involved in the Breach;
      3. A description of the steps the affected individual should take in order to protect himself or herself from potential harm resulting from the Breach;
      4. A description of what the Component is doing to investigate and mitigate the Breach and to prevent future Breaches; and
      5. 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.
    5. In the case where there is insufficient or out-of-date contact information:
      1. For less than ten (10) individuals, a substitute form of notice shall be provided such as a telephone call.
      2. 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:
        1. Post a conspicuous notice for ninety (90) days on the homepage of its website that includes a toll-free number; or
        2. 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.
    6. 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 2-4 above, contact the patient by telephone or other means, as appropriate.

  2. Media Notification

    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.


  3. HHS Notification

    1. 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.
    2. 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.

  4. Law Enforcement Delay

    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:

    1. 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;
      or
    2. 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.
Notes
  1. Dates of official enactment and amendments: 06/19/06
  2. History: Date of last revision: 08/26/2013
  3. Cross References:

About This Policy

Effective Date: June 19, 2006
Supersedes:
Issuing Authority: Vice President, Information Technology & Chief Information Technology Officer
Responsible Officer: Vice President, Information Technology & Chief Information Technology Officer
NYU Footer