Security and Privacy Incident Response Plan

Policy Statement

All members of Business are responsible for protecting the confidentiality, integrity, and availability of data created, received, stored, transmitted, or otherwise used, irrespective of the medium on which the data resides and regardless of format (e.g., electronic, paper, fax, CD, or other physical form).

In the event the confidentiality, integrity, or availability of data is compromised and a suspected incident has occurred, the incident should be reported immediately to the Information Technologies & Services  (ITS) AND to the Business Owner. 

Reporting incidents quickly regardless of certainty or magnitude is critical to ensure the appropriate teams can respond and contain the incident as soon as possible.

Reason for Policy

Privacy and/or information technology (IT) security incidents can occur at any time and of varying magnitude. Identifying and resolving incidents in an organized systematic way is a vital component of our overarching compliance programs. This policy provides a framework for identifying, assessing, reacting to, communicating about, and documenting an incident and corresponding remediation plans.

Who Should Read this Policy

All users of Business.

Principles

Security and privacy incidents must be (1) reported, (2) identified, (3) declared, (4) responded to, (5) remediated, and (6) resolved with adequate record-keeping. Detailed requirements for each of these steps are below.

1. REPORT THE INCIDENT- If you know or suspect any unusual or suspicious behavior that does not match your expectation of good security or privacy management, immediately report the incident to your supervisor and ITS Support right away. Even if you are not certain or cannot confirm the incident, it’s imperative that the incident is reported quickly so the right personnel can investigate as soon as possible. 
   1. Filing or reporting an incident is always done without fear or concern of retaliation.
   2. There are many different types of incidents that can be reported to ITS. Examples of incidents include, but are not limited to, the following:
      1. Patient information or Personal Identifiable Information misdirected or disclosed via mail, fax, verbal means
      2. Medical record documents or Personal Information are misplaced, stolen, lost
      3. Medical record documents or Personal Information are exposed (e.g., files left open on computer), improperly disposed of (e.g., not shredded) or stored (e.g., not locked or protected)
      4. User accesses system or application with credentials other than his/her own
      5. Unauthorized access to a system, application, or document
      6. A device (e.g., laptop, smartphone, desktop, tablet, removable storage, smart watches, cameras, voice recorders, etc.) containing Business data is lost, stolen, or otherwise unaccounted for
      7. A rogue device is connected to the network which impacts or prevents others from working
      8. System or individual is infected with malware or phishing (e.g., virus, ransomware)
      9. Potential data loss due to a malware infection
2. INVESTIGATE THE INCIDENT - Each reported incident must be investigated. 
   1. Confirmed incidents will be categorized as follows:
      1. Unauthorized or suspicious activity on Business network, including systems or applications
      2. Business data is lost, stolen, misdirected to, or otherwise shared with an unauthorized party
      3. A system on Business network is unknown
      4. A system on Business network is infected with malware or otherwise compromised, targeted, or profiled
      5. Other suspected compromise of data confidentiality, integrity, or availability
   2. Identifying Affected Data
      1. As quickly as possible, reasonable effort must be made to identify the type of data affected by the incident upon discovery and/or declaration. Various regulatory reporting and/or notification requirements, including deadlines, must be adhered to in accordance with applicable state, federal, or regulatory agencies where applicable.
3. DECLARING THE INCIDENT- The ITS and Business Owner can declare a privacy or IT security incident. 
   1. It is the responsibility of these individuals to evaluate the reported concern using the tools and risk assessment guides expeditiously to determine its authenticity and severity. Severity judgments will be based on ongoing persistent threats, the volume of data involved, and the potential for reputational and/or financial harm to the institution, or any affected individuals.
   2. Low-scale severity incidents will be handled by the ITS team. For more severe incidents, the Business Owner will convene into a meeting the core members of the Security & Privacy Incident Response Team (SPIRT) and begin drafting the initial incident report. The initial details of the incident will be discussed with the SPIRT core team at this time.
   3. The primary purpose of SPIRT is to determine and guide the business’s response to an information security or privacy incident, up to and including the need to satisfy existing data breach notification statutes or processes as well as an institutional decision to notify individuals of a breach of their personally identifiable or protected health information.
   4. As warranted by the type and scale of the incident, any of the SPIRT virtual team members may be convened by a core team member based on the type and scope of incident. Virtual team members provide assistance, advisement, and expertise from their representative areas. 
   5. Other individuals not on the SPIRT core or virtual teams may be convened by a core team member based on the incident. Such individuals may include, but are not limited to, department administrators or subject matter experts.
4. RESPONSE TO INCIDENT
   1. Containing the Incident - Once an incident has been reported and declared, the incident must be contained to prevent further harm. By means of example, the following containment steps should be taken:
      1. For IT security-related incidents, such as an infected system on the Business network, any network cables should be disconnected immediately and the system should remain powered on to allow for further investigation.
      2. For incidents involving protected health information or personal identifiable information in paper form, immediate efforts should be made to retrieve any copies or gain assurances that all records are accounted for.
      3. Effective containment stops damage from being done and allows assessment of the scope of the incident and the initiation of remediation activities.
   2. Assigning Roles - Upon declaring the incident, the SPIRT core team members will convene the appropriate virtual team members including any additional resources necessary, such as storage facilities, out-of-band communication channels, or additional staff—and assign roles pertaining to the incident assessment and response:
   3. The incident lead is responsible coordinating all stages of the incident response process, and specifically, acts as the leader of the investigation. In addition, the incident commander has the following duties:
      1. Ensures the incident has been properly contained
      2. Serves as the primary contact for the incident
      3. Ensures appropriate stakeholders are designated specific roles and responsibilities
      4. Includes additional resources and SPIRT virtual team members, as appropriate
      5. Leads the incident responders to consensus on taking action or making decisions during the incident
      6. Establishes out of band communication channels, as appropriate
   4. The incident coordinator is responsible for the oversight of the incident response, including, but not limited to, the following duties:
      1. Coordinates all meetings, including place, time, attendees, conference bridges, etc.
      2. Aggregates documentation in a secured and centrally-stored facility (electronic/physical)
      3. Provides documentation related to the incident to the SPIRT core team
      4. Ensures adherence to this policy and any regulatory reporting requirements
      5. Ensures interview communication plans are established
      6. Establishes a response timeline
   5. The IT forensics investigator is responsible for the electronic discovery of data from in-scope systems, applications, or logs. Other duties may include:
      1. Collect and preserve any physical evidence in a forensically-sound manner
      2. Adhere to appropriate chain of custody procedures
      3. Perform searches for various keywords, timelines, etc.
      4. Document any relevant findings and provide to the incident coordinator
   6. The data analysis investigator is responsible for reviewing all aggregated documents, forms, transcripts, and other relevant materials. In addition, the data analysis investigator is responsible for the following duties:
      1. Validate the scope of the incident and possible root cause
      2. Establish the relevancy of all aggregated materials
      3. Collect materials from interviews, (e.g., transcripts, other artifacts, etc.) and presents to team for further review
      4. Quantify impact to Business and other affected individuals
      5. Establish proof of the incident
      6. Prepare incident reports and a comprehensive narrative of the incident
      7. Prepare any necessary presentation materials
   7. The communications coordinator must be prepared to respond to any authorized/approved party at any time throughout the incident. Responsibilities include:
      1. Maintain awareness of the incident status throughout the investigation
      2. Plan for controlled notifications to internal and external parties, including press releases, letters, website materials, or other notifications
5. REMEDIATE THE INCIDENT
   1. Maintaining Confidentiality
      1. In order to limit exposure and maintain confidentiality about the incident, limited information pertaining to the incident should be disclosed upon initial notification (e.g., type/category of incident, date occurred, reported by, etc.). An informed parties log may be kept to document the degree and reason to which all parties have been informed about the incident.
      2. Throughout all communications, the incident responders should be reminded of the confidentiality of the incident and that information must not be shared outside the response team unless warranted.
   2. Incident Report
      1. The initial incident report must be presented and reviewed at the convening of the SPIRT core team. The SPIRT data analysis investigator is responsible for compiling the data elements below as part of the incident response procedures. Appropriate templates are available based on the type of incident. Distribution and review of the working draft is restricted and must be conducted under privilege with a member of the Business included on any distribution list or at the review sessions. The incident report may contain the following attributes:
         1. Incident name
         2. Incident number
         3. Incident description and type
         4. Date and time declared
         5. Date and time discovered/reported
         6. Date and time occurred
         7. Date and time contained
         8. Date and time remediated
         9. Assets or systems involved
         10. Data involved, including data type, and independent verification
         11. Individual(s) involved
         12. Individual(s) affected
         13. Root cause analysis
         14. Containment steps and verification
         15. Comprehensive response steps/action log
         16. Remediation steps
         17. Communications plan
         18. Regulatory reporting requirements
         19. Lessons learned
6. CLOSING THE INCIDENT
   1. Closing an incident indicates that the incident has been completely contained, remediated, and properly reported. In order to close an incident, all attributes in the incident report must be completed, as defined in Incident Report.
   2. Incidents can only be closed by consensus of the SPIRT core team.
   3. A post-mortem lessons learned meeting should be held within ten business days to review the incident and adherence to this policy for any future modifications. An independent reviewer may be engaged to provide additional feedback on the incident handling procedures and records.