The following process has worked well for me over the last 10+ years of writing “Management” (“Top Down”, “Risk Based”, & “Business Due Diligence”) CIRPs.
My CIRPs contain a “CIRP Management Overview” narrative that the CISO can provide their BOD/EMT to provide a high level linkage of Cyber Risks (typically from the Annual Report) all the way through (“Top Down”) the CIRP to include Roles & Responsibilities tables for each specific Use Case.
First Step
(This assumes you have all the necessary buy in, funding, etc.)
Develop a Cyber Risk Narrative that resonates with senior business management (e.g. Board of Directors [BOD], and chief executives).
If you are a public company, the first/best place to start is your Annual Report (SEC10-K).
After a decade of looking at Annual Reports (10-K) here are some examples:
“Ransomware”, “Employee Malfeasance”
“Acquisitions”, “state sponsored intrusions”
“Loss of life”. “harm to the environment”, “litigation”
“Status updates on incidents are provided to senior management and to the Board, as appropriate”, “Respond to cyber threats 24 hours a day, 365 days a year”
“business information and that of its employees, customers, partners and other third parties”
Second Step
Identify / develop Use Cases that directly or indirectly align with all of the risks in your Risk Narrative. If your 10-K lists “Insider Threat” as a risk, your CIRP should have an Acceptable Use Violation (AUV) Use Case. So, when an insider is doing something in violation of the acceptable use policy (threat behavior), you have a “response” ready to go.
Identify / develop narratives in the CIRP that align with these risks. For example, your Cyber Intrusion Use Case should also indirectly align to address the “Insider Threat” risk that was mentioned in your 10-K. Intrusion events should contemplate the possibility of the intrusion being from an “Insider”. Not every risk requires a unique Use Case.
Third Step
For each Use Case develop a Requirements Driven Execution based Roles & Responsibilities table. Inside this table, list all of the possible “Requirements” both business and technical (see image below) that may come into play.
These requirements are not meant to be “prescriptive” but rather “contemplative”. Each incident has the potential to be different.
For each requirement, assign the individual you would expect to either “do” the task, or the person who would manage the team doing the task.
The CIRP should provide a brief narrative for each requirement. I view the CIRP as an “operational” document with the “who” & “what”. The technical “how” narrative is usually contained in a “Process Guide”
I’ve seen “Process Guides” used in place of Use Cases. Just make sure they include both technical and business requirements.
Fourth Step
Include a CIRP Management Overview in your CIRP that looks something like this:
- Information Security 101
- Cybersecurity risks facing the company
- Incident Response 101
- The CIRP
- Three functions of a CIRP
- The Seven CIRP Audiences
- Use Cases
- How they align to the risks in #2
- Requirements Driven Execution
- Common Roles & Responsibilities Table as an Example
- Most common requirements
- By name assignment for each requirement
- Common Roles & Responsibilities Table as an Example