Preparedness for a Cyber Incident: Developing an Incident Response Plan, Identifying the Team and Practising

General overview

Why preparation, stakeholder identification and practice is important

No organisation of any scale presently operates without substantial reliance on information technology – servers, desktops, mainframes, cloud computing infrastructure, supervisory control and data acquisition systems, programmable logic controllers and internet of things devices are but a few of the technologies and systems used in the modern IT environment. Unfortunately, these systems constantly face a range of internal and external cybersecurity threats – from the routine to the advanced nation state. When threats to these systems manifest as events or incidents, organisational capability to react appropriately to minimise the effects almost always will depend on successful advance planning and preparation as codified in a written incident response plan that is developed and tested for effectiveness well before the incident arises.

In preparing to respond to a cyber incident, a plan is a necessary, but alone insufficient, element of incident preparedness for an organisation. To use a well-worn military phrase, 'no plan survives first contact with the enemy'.[2] This short statement brings to the fore two of the most important lessons that experienced cyber incident response professionals observe. No plan can foresee every eventuality that will arise in a given incident. As such, the incident response plan must be flexible and agile enough to respond to a variety of unforeseen circumstances, not wooden and overly cumbersome with internal requirements that are impossible to meet in actual operation. The second lesson, derived from the first, is that testing the plan under a variety of circumstances is a critical element of executing and achieving the central mission of any plan – to mitigate the consequences of an event or incident when one emerges.

This chapter addresses strategic and tactical considerations in formulating an incident response plan and the need for, and benefit from, practising a plan before an incident emerges.

Development of incident response plans

Overview

The European Union Agency for Network and Information Security provides a succinct summary of the definition and purpose of the incident response plan:

Incident response and management is the protection of an organisation's information by developing and implementing an incident response process (e.g., plans, defined roles, training, communications, management oversight) in order to quickly discover an attack and then effectively contain the damage, eradicate the attacker's presence, and restore the integrity of the network and systems.[3]

While incident response planning traditionally has focused heavily on IT security processes and procedures, as the legal and operational risks arising from incidents continue to increase due to the proliferation of operationally impactful malware, there is a commensurate need to develop a 'whole business' approach to planning for incident response. In this section, we address certain strategic considerations when formulating a plan to address current risks – legal considerations regarding the need for an incident response plan and how that plan is structured and executed, and governance considerations related to staffing the plan. Finally, there is an outline of specific tactical elements and components of a plan.

Legal considerations

An important starting point for the structure and execution of an incident response plan is the legal backdrop against which the plan will be executed. There are two overlapping but distinct legal elements: (1) the direct or indirect regulation that informs the content or timing relating to the incident response plan; and (2) issues relating to the structure of the investigation that can affect legal privilege and the discoverability of information generated during an investigation.

Regulatory considerations

With increasing regulation in the area of information security, a fundamental element of any plan is that it will satisfy the basic legal requirements imposed by relevant regulators. This can include direct regulation regarding the requirement to have a plan, such as the US Health Insurance Portability and Accountability Act (HIPAA) Security Rule, which requires certain entities to have the ability to identify and respond to security incidents and to have contingency plans in place.[4] In addition, regulator notification, reporting requirements and other legal obligations can materially affect how a plan is structured and implemented. The most prominent example of this arises out of the breach notification requirements of the EU General Data Protection Regulation (GDPR). Under Article 33(1) of the GDPR, entities may have as little as 72 hours after becoming aware of a breach of personal information to satisfy certain notification obligations.[5] The Information Commissioner's Office (ICO) – the data protection enforcement authority in the United Kingdom under the UK Data Protection Act 2018 – has published guidance establishing that subject organisations must have an incident response plan that covers the following checklist to ensure GDPR compliance:

  • allocating responsibility for managing breaches to a dedicated person or team;
  • escalating a security incident to the appropriate person or team to determine whether a breach has occurred;
  • assessing the likely risk to individuals as a result of a breach;
  • notifying the ICO of a breach as necessary; and
  • informing affected individuals of a breach as necessary.[6]

Additionally, a number of regulators and other government departments have issued legal guidance regarding incident handling that should be considered in the context of developing an incident response plan. The ability to map the steps in a plan to these guidance documents provides a strong basis to assert that the plan and response are legally well founded. Examples of guidance used in the United States to inform the content of incident response plans include the Federal Trade Commission's 'Data Breach Response: A Guide for Business'[7] and the US Department of Justice Criminal Division guidelines, titled 'Best Practices for Victim Response and Reporting of Cyber Incidents'.[8]

Finally, one notable regulatory development that needs to be factored into any response plan is related to ransomware incidents and the increased focus being paid to money laundering and terrorism financing risks due to the uptick in size of reported ransom payments.[9] On 1 October 2020, the US Department of the Treasury (the Treasury) issued a pair of advisories to alert companies about risks associated with ransomware.[10] The first advisory from the Treasury's Financial Crimes Enforcement Network (FinCEN) provides general information on the role of financial intermediaries in the processing of ransomware payments, and a list of ransomware-related financial red flags, including instances in which organisations in high-risk sectors (e.g., government, financial, educational, healthcare) engage in transactions with companies known to facilitate ransomware payments. The second advisory from the Treasury's Office of Foreign Assets Control (OFAC) highlights the sanctions risks associated with facilitating ransomware payments on behalf of victims targeted by malicious cyber-enabled activities. Taken together, these guidance documents should be factored into a response plan, with a key planning consideration being the identification of a vendor that has robust procedures in place to mitigate OFAC-related risk in the event an organisation is faced with a decision of whether to pay a ransom.

At bottom, legal and regulatory issues related to an organisation's incident response processes are evolving rapidly, and it is important to track these legal requirements and understand how they may have a material effect on the resources, structure and language used to describe an incident in response planning.

Legal privilege issues

A consideration in forming an incident response team is the extent to which certain legal privileges may be implicated in aspects of the response. As a general proposition, an incident response plan should provide guidelines for identifying incidents that present material legal, regulatory, operational, commercial or reputational risk and, for such incidents, structuring the incident response team in a way that maximises the ability to assert applicable legal privileges, as appropriate.

While it is beyond the scope of this chapter to discuss the complex nuances of global privilege law,[11] a critical action that needs to occur at the outset of a response is determining whether the organisation will seek to assert privilege over communications and documents created during the response and investigation, and the scope of such privilege. As described in more detail in Chapter 3 of this book, in the US a number of courts have recognised and protected the privilege of the work of internal teams during incident response intrusion investigations when the direction of that work was properly structured.[12] In 2020, two decisions from the same US court addressing privilege issues involving a single data security incident that reached different outcomes provides some insight on consideration of how to structure engagements to maximise that ability to assert privilege. The decisions were issued in a case arising from a 2019 incident involving a large banking entity that allegedly impacted the information of 100 million consumers.[13] Plaintiffs in the case were seeking access to various vendor reports about the incident. In the first decision, the court disallowed a claim of privilege over the work of the forensic vendor that conducted the incident response investigation, with the opinion highlighting the fact that the vendor retention leveraged a pre-existing agreement with the company, as opposed to a bespoke agreement to support legal counsel. The vendor's report was shared for business reasons both internally and with its auditor, and the forensic vendor was not paid out of the legal budget.[14] In the second opinion, the work of a different consultant was deemed protected from disclosure, with the court matter highlighting certain specific legal considerations that drove the consultant's retention, the fact that the retention agreement was bespoke to the engagement, and that circulation of the report was significantly circumscribed.[15] While only a single decision from one US court, these procedural considerations are notable to contemplate as a plan is developed.

Governance considerations

The first two elements of the ICO checklist (see 'Regulatory consideration') touch on the need to allocate responsibility within an organisation and ensure that the right levels of an organisation are notified when an incident occurs.[16] These governance considerations are at the foundation of any incident response plan. The US National Institute of Standards and Technology (NIST) Computer Security Incident Handling Guide highlights the fact that an organisation's overall management structure and size can affect the management model employed, highlighting that in some instances a centralised team is best while in others a distributed or coordinating model can work.[17] Regardless of the model, most well-formed incident response teams either explicitly or implicitly follow the Gold-Silver-Bronze, or Strategic-Tactical-Operational, command structure developed by the United Kingdom Metropolitan Police Service in 1980 and currently codified in the London Emergency Services Liaison Panel's Major Incident Procedure Manual.[18] This crisis management framework generally has three management tiers:

  • Strategic or Gold Commanders are responsible for preparing the strategy for their organisation's role in the incident. He or she retains overall command of resources but delegates tactical decision making to a Silver Commander.[19]
  • Tactical or Silver Commanders are responsible for planning the tactics to be adopted to achieve the strategy set up by a Gold Commander. Silver Commanders should be located where they can most effectively carry out their responsibilities but should be distanced from the immediate response activities.[20]
  • Operational or Bronze Commanders control and utilise the resources of their respective service within a specific area to implement the tactics prepared by a Silver Commander.[21]

It is important to note that under this structure, competency and experience drives the leadership designation, not title.

Both NIST and the International Organization for Standardization (ISO) adopt this pyramid governance structure in practice through the designation of incident response leads and the recognition that, in many instances, these leaders will not perform any actual incident handling.[22] The core benefit of a plan that is consistent with these standards is that it enhances the ability to ensure that appropriate individuals are part of the response leadership, that they are engaged at the right time in the response, and that operational and crisis management responsibilities are aligned.

In developing the governance framework of a response plan, and the general roles and responsibilities of its strategic, tactical and operational teams and their individual members, an organisation should consider its business structure and identify, assess and prioritise the various risks to the organisation that can arise from a security incident:

  • the nature of the business and its operations (e.g., whether the business is consumer-facing or business-to-business, provides network, data or professional services, or manufactures and sells goods or connected devices, and the sensitive customer, employee or organisational information or other assets that require protection);
  • the structure of the organisation, including size and complexity (e.g., whether it has global operations, geographically disparate functions, a parent-subsidiary relationship that must be aligned, or a segmented or third party-hosted computing infrastructure); and
  • risks related to a declared security incident, which may be reputational, commercial, legal (contractual/regulatory) or operational, and may affect the physical safety of customers or employees, or the security, privacy, confidentiality, integrity or availability of sensitive data under the control or in the possession or custody of the organisation.

Components of an incident response plan

A comprehensive framework of the individual components of an incident response plan is available in the form of guidance issued to its examiners by the US Federal Financial Institutions Examination Council (FFIEC), which is a council of US financial regulators whose responsibilities include setting the information security standards of federally chartered financial institutions:

The institution's program should have defined protocols to declare and respond to an identified incident. More specifically, the incident response program should include, as appropriate, containing the incident, coordinating with law enforcement and third parties, restoring systems, preserving data and evidence, providing assistance to customers, and otherwise facilitating operational resilience of the institution. . . .
Preparation determines the success of any intrusion response. Such preparation involves defining the policies and procedures that guide the response; assigning responsibilities to individuals; providing appropriate training; formalizing information flows; and selecting, installing, and understanding the tools used in the response effort. Additionally, management should define thresholds for reporting significant security incidents, and consider developing processes for when the institution should notify its regulators of incidents that may affect the institution's operations, reputation, or sensitive customer information.[23]

In light of the FFIEC guidance, and similar guidance released by NIST,[24] the US Federal Trade Commission[25] and the US Department of Justice,[26] among other incident response guidelines, an incident response plan should address the following elements:

  • what constitutes an incident as opposed to a security event;
  • the process for formally declaring an incident;
  • the make-up of and process for assembling the incident response team;
  • guidance for management's handling of incidents, including roles and responsibilities, span of authority and span of control;
  • guidance on operational handling of incidents, including evidence preservation and containment;
  • guidance for information sharing, both internally and externally;
  • authority to declare an incident a breach, or other legally significant designation;
  • considerations for determining whether to engage external support parties and contact information for those parties (e.g., specialised computer forensics, legal consultants, credit monitoring and a call centre);
  • guidance for engaging law enforcement agencies; and
  • guidance for remediating incidents and conducting post-incident reviews.

The elements outlined above reflect regulatory and industry guidance relating to incident response plans. Generally, these plans have a strong focus on managing a breach of confidential information, particularly personally identifiable information, protected health information or other sensitive data. As noted above, incidents are occurring that affect the operational functionality of the systems and may render an organisation incapable of performing almost any function that relies on IT systems. For example, based on public reports, the NotPetya malware that struck major companies around the world functionally rendered several Fortune 1000 companies inoperable.[27] Moreover, this was not a one-off event – for example, in 2021, major global corporations such as CNA Insurance and Honeywell experienced significant operationally impactful events due to ransomware.[28]

Unfortunately, the lessons of these operational incidents have not yet been fully incorporated into the regulation, literature and guidance, and are not fully considered in many incident response plans. Based on direct experience in advising organisations following malware incidents that have severely affected business operations, including the NotPetya event, organisations would be well served by reviewing their existing incident response plans with the following questions in mind:

  • Does the current incident response plan integrate with the organisation's business continuity and disaster recovery plan from both an operational and management perspective?
  • How will the incident response plan be carried out if all the communications infrastructure owned and managed by the organisation is inoperable?
  • Has the organisation identified and mapped its critical business services to understand what systems need to be brought online, and in what order, in the aftermath of an operationally major event?
  • Many organisations have in place incident response retainers with third parties; has the organisation assessed and identified a third-party vendor to assist with the provision of surge IT capacity to assist in restoring the computing environment after an operational event?
  • Does the organisation understand key external dependencies and how to restore them in the aftermath of an operationally major event?

The law, regulation and guidance will continue to reflect the growing threat presented by these operational events. One recent example is the October 2020 guidance issued by the FFIEC, directly addressing operational resilience and specifically discussing resilience considerations for operationally impactful cyber events.[29]

Another consideration for an incident response plan is the identification of the relevant stakeholders within the organisation as an incident can implicate potentially all aspects of an organisation and thinking through the multidimensional team is important. An incident response plan should identify the strategic or tactical leads for each potentially relevant function within the organisation. These functions will vary depending on the organisation's complexity and mission, but could include the following:

  • Operations. The business units within the organisation are generally responsible for understanding and mitigating the operational effects on the organisation, including outcomes that may result from impairment to affected IT systems and capabilities, as well as any loss of goodwill.
  • Legal. The legal staff are generally responsible for identifying and mitigating legal risks associated with the incident, including ensuring compliance with relevant regulatory obligations, privacy and securities laws, interfacing with regulators, and managing or avoiding potential disputes and litigation. As noted above, under precedent such as In re KBR, to maximise claims of legal privilege, the general counsel or other legal leadership must direct and control the investigation into the incident.
  • Communications. The communications staff are generally responsible for ensuring consistent messaging that complies with business requirements, including with respect to the public, investors, affected individuals or customers, and in certain employee communications within the organisation. Fulfilling this function will usually require coordination with the legal function to ensure that communications comply with applicable legal requirements and otherwise consider post-breach legal risks.
  • Technical. The technical team will typically include members of the information security function as well as the operational IT groups. The security team members will typically focus on investigating the incident and formulating an appropriate containment strategy. IT staff will need to assist the investigators while also remediating the incident as appropriate. This may include a range of possible responses, from restoring a handful of affected systems to implementing the disaster recovery protocol.
  • Sales/Account Management: In incidents involving business to business relationships, sales and account teams with the direct client relationships can prove instrumental to navigating and communicating with customers. Training sales personnel on the basics of incident response and what to say and not to say while an incident is occurring is key, as customers will be reaching out to the account representatives directly and demanding answers.
  • Finance. The finance team will generally be responsible for mitigating any financial effects an incident might have, including planning around lost revenue and securing necessary funding for external costs. The finance team may also be responsible for insurance recovery.
  • Human resources (HR). The HR team will generally be responsible for ensuring the incident response complies with applicable employment policies (such as overtime rules). HR may also be implicated to the extent that employee malfeasance is found to be a contributing factor to the incident, employee personal information may have been compromised, or employee morale may need to be managed as part of the response efforts.[30]

The plan also should identify key external advisers who would be called upon during a response, such as a cyber incident response firm, crisis communications firm and legal counsel. By identifying and establishing engagement terms with these third-party vendors, the organisation's response can be significantly streamlined and more efficacious.

Finally, many organisations find it constructive to build relationships with third parties such as law enforcement, cybersecurity-focused government stakeholders and key regulators in advance of an incident. When an event happens, established relationships that facilitate the disclosure of the incident to a government stakeholder can go a long way towards mitigating the overall organisational risk to that sometimes key constituency. And a response itself can be materially assisted by information flow to and from the government, be it law enforcement such as the US Federal Bureau of Investigation or government programmes specifically designed to reduce cybersecurity risk, such as the UK's Government Communications Headquarters – National Cyber Security Centre public-private information sharing programme.

Practising the incident response plan

A growing component of the cyber programme for organisations with a relatively mature cybersecurity capability is the regular mandatory testing of their incident response plans. The US Department of Homeland Security Exercise Evaluation Program has developed a robust programme to test incident response plans and identified seven types of exercises that can facilitate their adoption and execution.[31] The first four are discussion-based exercises, each with a different focus and rules, but all exercises usually include a facilitator who leads the discussion and records input and responses:

  • Seminar: An informal discussion, designed to orient participants to new or updated plans, policies or procedures.[32] In the information security context, a seminar could be scheduled to facilitate a cross-organisational discussion regarding how, for example, information security and IT management interpret aspects of the span of control provisions within an information response plan.
  • Workshop: Similar to a seminar, but more focused on forward-looking risks or changes.[33] An example of a workshop might be how the incident response team may incorporate the growing risk of operationally high-risk malware into the incident response policy.
  • Tabletop exercise: Involves key personnel discussing simulated situations in an informal setting.[34] These situations are designed to assess plans, policies and procedures on a given set of facts and to discuss the different perspectives of the participants.
  • Games: Offers a simulation of operations. It can often involve two or more teams, usually in a competitive environment, using rules, data and procedures designed to depict an actual or assumed real-life situation.[35] Games require significantly more investment of time and effort, as the facilitator must react to responses by the game participants within the rules established for the game. An example of a game would be one in which management must decide whether to pay a ransom in a ransomware situation and a discussion is facilitated to bring varying considerations to the fore.

Operations-based exercises validate plans, policies, agreements and procedures, clarify roles and responsibilities, and identify resource gaps in an operational environment. Types of operations-based exercises include the following:

  • Drill: A coordinated, supervised activity focused on a single specific operation or function within an organisation.[36] A drill might entail an information security 'red team' operating within carefully prescribed parameters attempting to penetrate a network without triggering alerts so as to test intrusion detection tools and personnel.
  • Functional exercise (FE): Similar to a game but can occur over a longer period and is designed to test coordination, command and control between various areas of the organisation.[37] As in a game, facts relating to a hypothetical incident are presented to participants, but there is less discussion and more real-time decision-making among the stakeholders. An example again could be similar to the game situation of a ransomware attack, but the FE involves less discussion and more structure to emulate the organisation's decision-making process.
  • Full-scale exercise: A multi-stakeholder exercise involving functional areas.[38] In the information response planning context, such an exercise might involve engaging with key third-party vendors as participants in the exercise. Other options include retaining former regulators or reporters to simulate third-party reaction to decisions made by the incident response team.

At its broadest, exercises can touch on all aspects of the incident response plan and all relevant stakeholders can participate, including business unit leaders, communications, legal, the executive management team, the board and external stakeholders. Capturing and incorporating feedback and the lessons learned to improve the response plan is an important aspect. Each participant should provide feedback not only on the exercise itself, but also on whether the existing response plan adequately informed them of their roles and responsibilities and provided sufficient guidance to execute their roles.

In essence, the most carefully drafted and considered plan on paper is worthless if, during a crisis, those charged with executing it fail to know and understand their responsibilities within a well-considered framework. The best-prepared organisations exercise their plans regularly in different ways and with different methods for continuous improvement.


Footnotes

1 David C Lashway and John W Woods, Jr are partners at Baker McKenzie.

2 This quote derives from Prussian General Helmuth von Moltke the Elder. See Helmuth Karl Bernhard von Moltke, Über Strategie (Mittler, 1891) ('The material and moral consequences of every major battle are so far-reaching that they usually bring about a completely altered situation, a new basis for the adoption of new measures. One cannot be at all sure that any operational plan will survive the first encounter with the main body of the enemy. Only a layman could suppose that the development of a campaign represents the strict application of a prior concept that has been worked out in every detail and followed through to the very end.').

3 European Union Agency for Network and Information Security, 'Strategies for Incident Response and Cyber Crisis Cooperation' 7 (ver. 1.1 2016) (citing SANS Critical Security Control 18).

4 The US Health Insurance Portability and Accountability Act of 1996 [HIPAA] Security Rule requires covered entities and business associates to: identify and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity or business associate; and document security incidents and their outcomes. 45 CFR Section 164.308(a)(6). The HIPAA Security Rule also requires HIPAA-covered entities and business associates to establish and implement contingency plans, including data backup plans, disaster recovery plans and emergency mode operation plans. 45 CFR Section 164.308(a)(7).

5 General Data Protection Regulation [GDPR], Article 33.

6 Information Commissioner's Office, 'Guide to the General Data Protection Regulation (GDPR)' (August 2018), at 233, available at https://ico.org.uk/media/for-organisations/guide-to-the-general-data-protection-regulation-gdpr-1-0.pdf.

7 US Federal Trade Commission, 'Data Breach Response: A Guide for Business' (September 2016), available at https://www.ftc.gov/system/files/documents/plain-language/pdf-0154_data-breach-response-guide-for-business.pdf.

8 US Department of Justice, 'Best Practices for Victim Response and Reporting of Cyber Incidents' (version 2.0 September 2018), available at https://www.justice.gov/criminal-ccips/file/1096971/download.

9 An overview of the ransomware payment market and increase in payments is found at the CNBC Article 'The extortion economy: Inside the shadowy world of Ransomware payouts' (6 April 2021). Available at www.cnbc.com/2021/04/06/the-extortion-economy-inside-the-shadowy-world-of-ransomware-payouts.html.

10 See Department of the Treasury Office of Foreign Asset Control, 'Advisory on Potential Sanctions Risks for Facilitating Ransomware Payment' (1 October 2020) (OFAC Advisory) available at https://home.treasury.gov/policy-issues/financial-sanctions/recent-actions/20201001; Department of the Treasury Financial Crimes Enforcement Center, 'Advisory on Ransomware and the Use of the Financial System to Facilitate Ransom Payments', FIN-2020-A006 (Oct. 1, 2020) available at www.fincen.gov/resources/advisories/fincen-advisory-fin-2020-a006 (FinCen Advisory).

11 A helpful overview of privilege law across certain key jurisdictions can be found at the Baker McKenzie Global Privilege Center. Available at https://globalprivilege.bakermckenzie.com/.

12 See, e.g., In re Premera Blue Cross Customer Data Sec. Breach Litig., 296 F. Supp. 3d 1230 (D Or 2017); In re Experian Data Breach Litig., Case No.15-mdl-1592, 2017 WL 4325583, 2017 US Dist LEXIS 162891 (CD Cal 18 May 2017); In re Target Corp. Customer Data Sec. Breach Litig., MDL No. 14-2522, 2015 WL 6777384, 2015 US Dist LEXIS 151974 (D Minn 23 Oct 2015); Genesco, Inc. v. Visa U.S.A., Inc., 302 FRD 168 (M.D. Tenn 2014); In re TJX Cos. Retail Sec. Breach Litig., Case No. 1:07-cv-10162 (D. Mass. 9 Nov 2007) (Minute Order).

13 Rachel Sandler, 'Capital One Says Hacker Breached Accounts Of 100 Million People; Ex-Amazon Employee Arrested', Forbes (29 July 2019) available at www.forbes.com/sites/rachelsandler/2019/07/29/capital-one-says-hacker-breached-accounts-of-100-million-people-ex-amazon-employee-arrested/?sh=4da880fd41d2.

14 See In re Capital One Customer Data Security Breach Litigation, 2020 U.S. Dist. LEXIS 91736, Case No. 1:19-md-02915 (E.D. Va. May 26, 2020) (Anderson M.J.) Docket Entry 490 affirmed by In re Capital One Customer Data Security Breach Litigation, 1:19-md-02915 (E.D. Va. June 25, 2020) (Trenga J.) Docket Entry 641.

15 See In re Capital One Customer Data Security Breach Litigation, 1:19-md-02915 (E.D. Va August 24, 2020) (Anderson M.J.) Docket Entry 804.

16 Guide to the GDPR (footnote 6), at 233.

17 National Institute of Standards and Technology [NIST], Spec. Pub. 800-61, 'Computer Security Incident Handling Guide' 13 (revised 2 August 2012), available at https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf.

18 London Emergency Services Liaison Panel, Major Incident Procedure Manual (9th ed. 2015), available at https://www.met.police.uk/SysSiteAssets/media/downloads/met/about-us/major-incident-procedure-manual-9th-ed.pdf.

19 ibid., at Section 6.5.1.

20 ibid., at Section 6.4.1.

21 ibid., at Section 6.3.1.

22 NIST Spec. Pub. 800-61 (footnote 17), at 13. ISO/IEC 27001 establishes that organisations 'should ensure a consistent and effective approach to the management of information security incidents, including communication on security events and weaknesses'. ISO/IEC, No. 27001, Information Security Management, at A.16.1. (2013).

23 The Federal Financial Institutions Examination Council, IT Examination Handbook for Information Security, Section III.D (September 2016).

24 NIST Spec. Pub. 800-61 (footnote 17).

25 'Data Breach Response: A Guide for Business' (footnote 7).

26 'Best Practices for Victim Response and Reporting of Cyber Incidents' (footnote 8).

27 See Andy Greenberg, 'The Untold Story of NotPetya, the Most Devastating Cyberattack in History', Wired Magazine, September 2018, available at www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed-the-world/.

28 See Eduard Kovacs, 'Honeywell Says Malware Disrupted IT Systems', Security Week (March 24, 2021) available at www.securityweek.com/honeywell-says-malware-disrupted-it-systems; Alicia Hope, CPO Magazine, 'Cyber Insurance Firm Suffers Sophisticated Ransomware Cyber Attack; Data Obtained May Help Hackers Better Target Firm's Customers' (April 5, 2021) available at www.cpomagazine.com/cyber-security/cyber-insurance-firm-suffers-sophisticated-ransomware-cyber-attack-data-obtained-may-help-hackers-better-target-firms-customers/.

29 See Press Release, Agencies release paper on operational resilience (Oct. 30, 2020), www.federalreserve.gov/newsevents/pressreleases/bcreg20201030a.htm.

30 See also NIST Spec. Pub. 800-61 (footnote 17), at 17 (identifying functional areas typically called upon in an incident response).

31 US Department of Homeland Security, Homeland Security Exercise and Evaluation Program (April 2013), available at https://www.fema.gov/media-library-data/20130726-1914-25045-8890/hseep_apr13_.pdf.

32 ibid., at 2 to 4.

33 ibid., at 2 to 5.

34 ibid.

35 ibid.

36 ibid., at 2 to 6.

37 ibid.

38 ibid.

Get unlimited access to all Global Investigations Review content