M.15) Establish information security incident management procedures

Category:        Corporate Information Security

Responsible:   CSR, PSR, CTO

Effort:              2 hours

Based on:       BSI IT Grundschutz M 6.1 / M 6.23 / M 6.58, M 6.59 / M 6.60 / M 6.61 / M 6.64 / M 6.66 / M 6.68 / M 6.114 / M 6.115 / M 6.119 / M 6.122 / M 6.130 / M 6.134; [1]

Also known as: Write down what you have to do in case of an emergency.

Although this safeguard is especially important for medium sized and large companies, this measure can also be valuable for small companies. This is not about defining the perfect incident management procedures, but much more about thinking ahead, recognizing possible emergency scenarios upfront and define basic operations which need to be done in case of an emergency. The following steps show how a startup can define incident management procedures. The CSR, PSR and CTO should do this together.

1) Find possible emergency scenarios based on M.1 e)


  • Breaches to Information security (DoS, Malware, etc.)
  • Loss, theft, unauthorized disclosure of confidential/business critical information
  • Breaches to physical security (or attempts to)
  • Breaches to private IT and accounts (Hack of social media profiles, stolen private phone, etc.)
  • Unavailability for more than x hours


2) Define how employees should respond to incidents

Create a one-pager for employees, in which they can find examples for emergencies and how they should react to them:

  • How to identify the emergency (symptoms)
  • Whom to call
  • How to behave
  • How to document the incident


3) Define how to deal with incidents

  • Create activity diagrams / checklists / working instructions to guide through handling an incident
  • Create a template for incident documentation


4) Test the procedures/checklists

It is necessary to test the defined incident checklists. If the team has defined the incident “very high server load leads to very low response times” and the response “start new server instances (automatically)” then such a scenario has to be tested. The checklists and working instructions need to be detailed enough, so that developers can handle this problem, also if the responsible for DevOps is not available.


5) Learn from incidents

In case of an incident it is necessary to document the event and to learn from it for similar events in future. M.18 shows a way how to learn from incidents and errors.


An example of an incident management document can be found in [1]. This reference describes the incident management procedures of the Heriot Watt University. Although this is a document for a medium sized organization, it can give good insights and tips on how to create such incident procedures.


[1] Heriot Watt University, “Information Security Incident Management Procedures,” [Online]. Available: https://www.hw.ac.uk/documents/information-security-incident-management-procedures.pdf . [Accessed 10 01 2016].



The information contained in this website is for general information purposes only. You can find more information about the accuracy of the information on the disclaimer and terms and conditions pages.