Preparedness for a Cyber Incident: Developing an Incident Response Plan, Identifying the Team and Practising
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’. 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
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.
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, 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.
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.
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. 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. 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.
Finally, 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’  and the US Department of Justice Criminal Division guidelines, titled ‘Best Practices for Victim Response and Reporting of Cyber Incidents’.
In essence, 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, 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. Two examples illustrate this point.
In the 2014 US federal appellate decision In re Kellogg, Brown & Root, Inc (In re KBR I ), the question at issue pertained to the circumstances in which a party could successfully assert that the work of an internal investigative team and counsel would receive the protection of attorney–client privilege in the United States. A lower court initially found that the internal investigation materials were not subject to the privilege because the investigation was ‘undertaken pursuant to regulatory law and corporate policy rather than for the purpose of obtaining legal advice’ and ordered the production of the materials. The federal appeals court vacated the district court’s discovery order. The appeals court particularly emphasised that the test for applying the privilege is whether obtaining or providing legal advice was ‘a primary purpose of the communications’, rejecting the rule that the privilege applies only if the communication would not have been made ‘but for’ the fact that legal advice was sought. Because KBR undertook the internal investigation to gather facts and ensure compliance with the law after becoming aware of the alleged misconduct, the appeals court found that the work was protected by the attorney–client communication privilege. In re KBR I rested, in part, on the fact that the lawyers were directly involved in the work of the various internal teams and those teams were working at the behest of counsel. As described in more detail in Chapter 3 of this book, 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.
A different but related consideration provides a second example. European law differs significantly in the approach to privilege afforded to the disclosure of confidential information relating to the attorney–client relationship. As set forth in the 2010 Akzo Nobel v. Commission decision, the European Court of Justice held that legal privilege extends to communications originating from independent lawyers (i.e., external counsel) for the purposes of the client’s rights of defence in competition investigations. This case has been interpreted broadly to apply outside the competition sphere, and is commonly referenced for the proposition that to claim privilege over communications, the communications must be between the organisation and an independent lawyer licensed in a EU jurisdiction. Accordingly, to the extent that an incident may involve an EU jurisdiction and an organisation would like to assert privilege over at least certain aspects of the incident response, the plan itself would probably need to reflect the early engagement of external counsel.
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. 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. 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. 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.
- 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.
- 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.
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. 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.
In light of the FFIEC guidance, and similar guidance released by NIST, the US Federal Trade Commission and the US Department of Justice, 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. Increasingly, however, 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. The shipping giant Maersk, according to public reports, lost functionality of more than 45,000 computers and 4,000 servers and shut down global operations from Mumbai to Los Angeles, Spain and the Netherlands. Moreover, this was not a one-off event – in March 2019 alone, Norsk Hydro, Momentive Performance Materials, Inc and Hexion, Inc all reported that material operations were badly affected following a malware outbreak.
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 and regulation are likely to continue to develop to reflect the growing threat presented by these operational events. As one of the first examples of this, the Bank of England has increased its focus on operationally major events and announced in March 2019 that it will begin stress testing banks later in the year to assess whether they can withstand a ‘severe but plausible’ cyberattack that has a major effect on operations.
Finally, it is important for an incident response plan to identify the relevant stakeholders within the organisation and to build relationships with key external resources and advisers. An incident response can implicate potentially all aspects of an organisation, and as such a multidimensional team will be required for responding to significant incidents. 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.
- 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.
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. 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. 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. 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. 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. 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. 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. 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. 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.
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-regulationgdpr-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-forbusiness.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.
10 756 F.3d 754 (DC Cir 2014) (Kavanaugh, J); see also In re Kellogg, Brown & Root, Inc., 796 F.3d 137 (DC Cir 2015) [In re KBR II ].
11 In re KBR I, 756 F.3d, at 756 (citing United States ex rel. Barko v. Halliburton Co., 37 F. Supp. 3d 1, 5 (DDC 2014)).
12 ibid., at 759 and 760.
13 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 (MD Tenn 2014); In re TJX Cos. Retail Sec. Breach Litig., Case No. 1:07-cv-10162 (D Mass 9 Nov 2007) (Minute Order).
14 Akzo Nobel Chemicals Ltd v. European Commission, Case C-550/07-P (14 Sep 2010).
15 Clinton R Long, ‘Akzo and The Debate on In-House Privilege in the European Union’, 8 BYU International Law & Management Review 1; Robert J Anello and Richard F Albert, ‘Erosion of the Corporate Attorney-Client Protection in Europe’, NY Law Journal (Jun 2017), https://www.law.com/newyorklawjournal/almID/1202788555189/.
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-manual9th-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 Andy Greenberg, ‘The Untold Story of NotPetya, the Most Devastating Cyberattack in History’, Wired Magazine, September 2018, available at https://www.wired.com/story/notpetya-cyberattack-ukraine-russiacode-crashed-the-world/.
28 Emma Stoye, ‘Hexion, Momentive and Norsk Hydro all hit by ransomware cyber attacks’, Chemistry World, 2 April 2019, https://www.chemistryworld.com/news/hexion-momentive-and-norsk-hydro-all-hit-byransomware-cyber-attacks/3010328.article.
29 Huw Jones, ‘Bank of England to test banks’ resilience to cyber attacks’, Reuters, 5 March 2019,
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.
36 ibid., at 2 to 6.