Incident management guideline

Introduction

Purpose

A QGEA guideline is non-mandatory and provides information for Queensland Government entities on the recommended practices for a given topic area.

The Incident management guideline has been developed to assist entities in developing an incident management policy that enables a planned, systematic approach to the handling of information security events and incidents. Entities that already have an incident management policy in place may use this guideline to check their approach is consistent with the incident management expectations of the Queensland Government.

Detailed guidance can be found in ISO/IEC 27035 Information Security Incident Management.

Audience

This guideline is primarily intended for:

• Queensland Government entity staff and operational areas involved in incident management activities
• information security governance bodies.

Scope

This guideline relates to the incident management and compliance management requirements encompassed by the Information and cyber security policy (IS18).

This guideline does not cover technical incident response activities. Appropriate containment, eradication, and recovery activities should be determined by an affected entity.

Background

Benefits of using the guideline

Adopting a comprehensive approach to incident management can help entities to:

• apply controls to help prevent, but also detect information security events and incidents
• undertake appropriate risk and impact assessment of information security incidents when they occur
• plan for and enhance holistic incident response actions
• minimise adverse effects on entity operations when incidents occur (understanding and linking incident management with entity risk, crisis, and business continuity management frameworks)
• learn from incidents, and use those findings to update information security policies, plans and supporting procedures.

Guideline structure

This guideline is structured to:

• provide an overview of incident management
• describe the five key phases of incident management
• describe key activities within each of the five phases
• provide entities with advice to help develop incident management policies.

Incident management overview

Incident management describes the collaborative activities and processes to handle information security incidents in a consistent, comprehensive, and effective way. This includes actions to detect, report, assess, respond to, deal with, and learn from incidents. Incident response describes the tactical level response to an incident and is often used to describe a more technical set of activities whereas incident management includes the comprehensive efforts to deal with the strategic implications beyond the limited scope of an entity’s impacted information and communication technology (ICT).

Incident management and incident response serve different, but complementary, functions that allow an entity to holistically deal with an incident. Both functions are critical, time sensitive, and are essential to maintaining business operations.

Developing plans that articulate a structured and repeatable process to manage incidents, enable entities to improve overall information security, enhance resilience, improve the prioritisation of resources, and support the collection of evidence to support investigations.

Incident management phases

ISO/IEC 27035 – Information Security Incident Management breaks the management of incidents into five key phases as illustrated in Figure 1. These phases form a repeatable process that will enable entities to facilitate evidence based continual improvement of internal procedures.

This section outlines the phases of incident management, and the key activities government entities should carry out to prepare for, respond to, and learn from an incident. Further reading of referenced policies and standards is strongly encouraged to prepare effectively for incident management.

Figure 1: The ISO/IEC 27035 Incident management process

Plan and prepare

Appropriate planning and preparation will improve entity incident management. Having a well-developed incident management policy that has been tested and rehearsed, is likely to enable an entity to successfully manage incidents when they occur. Recommended activities that should be completed include the development of incident management policy and supporting plans and processes, and the establishment and resourcing of appropriate incident management and incident response teams. The activities listed in this section are by no means exhaustive, and entities should complete activities in alignment with their risk tolerance and appetite.

What is an incident management policy?

An incident management policy (sometimes called an incident management plan) is a strategic document that outlines how an entity will prevent and prepare for, respond to, and recover from, information security incidents. This policy should define roles and responsibilities, identify obligations, provide escalation and communication processes, and outline the entity’s approach to restoring normal operations and minimising the impact of an incident. An incident management policy may be accompanied by copies of an entities incident response plan and playbooks.

Incident response plan

An incident response plan describes the operational level steps and process that are taken to respond to an incident. The primary goal of an incident response plan is to identify, contain and eradicate security threats as quickly and effectively as possible and as such is more technical in nature.

Playbooks

An incident response plan should provide straightforward steps to enable a response with minimum ambiguity, but it would be impractical for a single incident response plan to outline how to respond to all potential security incidents. For this reason, playbooks are developed to outline how to respond to specific types of security incidents.

Key activities

The key activities undertaken during the planning and preparation phase of incident management are:

• develop an incident management policy, incident response plan, and playbooks
• ensure that the incident management policy is integrated and aligns with other entity policies such as business continuity plans, disaster recovery plans, and risk management frameworks
• identify the processes to establish an incident response team and an incident management team. Ensure that an appropriate training program is developed and delivered to its members, including training in the specific incident management policy or incident response plan
• identify and define the key roles, responsibilities, and authorities of those involved in incident management (immediate points of contact for the incident response team, the incident management team, and executive leadership)
• understand relationships with internal and external stakeholders that directly relate to incident management and response and identify appropriate points of contact and communication channels
• rehearse and test the suite of documents, involve relevant stakeholders, and improve processes and procedures from lessons learnt.

Detection and reporting

Detection and reporting are the first operational phase of the incident management process. It involves the detection and collection of information associated with the incident. Incidents may be detected by internal, external, or open sources. Early detection of security events or incidents will reduce the likelihood of incidents occurring and reduce the chances of any impact on an entity.

This phase also includes the initial reporting of the incident. Entity incident management policies should define reporting procedures and contact points. These procedures should use templated formulas to ensure the required information is captured and then escalated as appropriate.

Queensland Government incident reporting requirements are outlined in the Information security incident reporting standard.

Key activities

The key activities undertaken during the detection and reporting phase of incident management are:

• employ detection systems which appropriately cover the full range of ICT assets used within the entity, such as:
  • automate alerts from security and/or monitoring systems
  • conduct vulnerability scanning
  • analysis of system logs.
• use defined and documented processes to report the detected information
• conduct regular security awareness training sessions for staff to support incident detection
• establish processes to ensure incidents are entered into an incident register upon detection.

Assessment and decision

This phase involves assessing the information gathered during the detection and reporting phase and covers the escalation of a security event to an incident where required.

Key activities

The key activities undertaken during the assessment and detection phase of incident management are:

• collate information relevant to the event through the sources identified in the previous phase
• escalation the detected incident, and any relevant supporting information, to the appropriate level of management for assessment
• the appropriate level of management should conduct an assessment to determine if the event is an information security incident or a false positive
• determine the incident type, scope, and business impact level
• ensure that appropriate logging of activities and decisions are made.

Response

The response phase of the incident response process primarily involves the containment, eradication, and recovery actions undertaken by technical response teams. These actions should be documented within the entity’s incident response plan and/or playbooks. Concurrently, the incident management team should be coordinating the stakeholders to mitigate and manage the impact of the incident on operations, staff or customers. The incident management team should also ensure that the entity is fulfilling its legislative or regulatory obligations (i.e. privacy, critical infrastructure, financial reporting).

Key activities

The key activities undertaken during the response phase of incident management are:

• Take the appropriate action to contain, eradicate and recover from the incident as outlined in the incident response plan and relevant incident playbook.
• Review the ongoing severity of an incident to determine if there is any need for external resources or assistance. If further assistance is required, the entity may escalate the incident as outlined in the Queensland Government Cyber Security Arrangements (QGCSA).
• Communicate the status of the incident, including appropriate details, with relevant stakeholders, both internal and external. Consider the value of intelligence gained through this incident for other stakeholders.
• Take steps to minimise or mitigate the impact of the incident on operations, staff, or customers (consider business continuity plans or disaster recovery plans).
• Ensure entity fulfils its legislative or regulatory reporting requirements.
• Ensure appropriate logging of evidence and actions taken.

Lessons management

This is an ongoing process that occurs throughout all incident management phases. The purpose is to undertake evidence based continual improvement to optimise entity processes and policy, including the incident management policy, incident response plan and playbooks. During an incident, positive and negative observations should be recorded. Once an incident has been resolved the observations should be analysed to provide insights into what went well and to identify any opportunities for improvement (the lessons identified, and any subsequent recommendations). This should be formalised in a post incident review. Met recommendations become ‘lessons learnt’.

Key activities

The key activities undertaken during this phase are:

• record observations (good and bad) throughout an incident
• following an incident, evaluate and analyse observations to identify lessons and any subsequent recommendations
• compile incident information and relevant lessons in a formal post incident review format
• share the post incident review as required, including for the meeting of reporting requirements
• subsequently make improvements to security controls, policies, planning and/or procedures based on lessons identified
• store complete and reliable records of the activities completed in accordance with the records governance policy (lessons identified that are actioned become lessons learned).

Developing incident management policies

This section provides guidance on how to develop a suitable incident management policy. A policy check list is available at Appendix A which can be used to assist in the planning and management of an incident.

Relevant legislation

When developing an incident management policy, entities should identify relevant legislative, regulatory, and policy obligations that may impact the incident management. These may include, but are not limited to the following:

• Cyber Security Act 2024 (Cth)
• Information Privacy Act 2009
• Information Privacy and Other Legislation Act 2023
• My Health Records Act 2012 (Cth)
• Privacy Act 1988 (Cth)
• Public Records Act 2023
• Security of Critical Infrastructure Act 2018 (Cth).

Planning principles

When developing an incident management policy and other related plans it is important to consider the following principles:

• Simplicity: plans should be simplistic and easy to follow during a crisis
• Focus: plans should be limited in scope to achieve realistic results and address the most likely and damaging incidents
• Flexibility: plans should be broad enough to apply to most situations, and easy to update as situations, threats and operations evolve
• Integration: incident management policies should be linked to the goals, objectives, and process in established policies such as business continuity plans, disaster recovery plans, and risk management frameworks
• Test and update: plans should be living documents and updated to apply lessons learnt and to reflect changes in the threat landscape or information environment.

Identify incident management methodology

Entities should align with an appropriate incident management standard or methodology such as ISO 27035, NIST 800-61, or COBIT DSS02.05 when developing an incident management framework. Entities should consider their resources, functions, and policy/regulatory requirements to select the appropriate methodology. Selecting an appropriate standard will assist in incident management planning.

Integration with established policy

incident management policies should be clearly linked to the goals, objectives, and processes in established entity policies such as business continuity plans and disaster recovery plans.

Plans should also align with whole-of-government policy such as the Queensland Government Cyber Security Hazard Plan (PDF, 1.88MB) to enable incidents with applicable security implications and/or consequences to be escalated to the appropriate level to enable inter-entity coordination and response.

Identify and register critical information assets and systems

It is vital that entities understand their information environment. This includes knowing what critical information assets and information systems underpin their entity’s critical business operations. Entities should identify and register all critical information assets, systems, and identify the recovery time objectives. The recovery time objectives of these systems should be integrated into the incident management policy as well as any business continuity plans.

Developing incident management policy

Entities should develop an incident management policy that outlines the framework for how security and business operations function together when a security incident occurs. Plans should include:

• Purpose and goal: Clearly articulating the goal and objectives of the entity’s incident management program will help to focus planning and incident management. It may be helpful to frame this by articulating the value and importance of incident management to the entity.
• Scope: The bounds and limitations of the entity’s incident management policy should be clearly articulated. This will assist in determining authorities and expediting decision making in an incident.
• Incident management roles and responsibilities: To avoid ambiguity, it is important to clearly articulate incident management roles and responsibilities early in the plan.
• Team structure: The policy should identify when an information security incident response team or incident management team will be established. This is an important step in an entity’s management of security incidents. The goal of establishing these teams is to provide entities with the capability for assessing and responding to information security events and incidents. The size, structure, and composition of the incident response team or incident management team should be appropriate to the context, size, and structure of the entity establishing the team.
• Processes and procedures: The incident management policy should articulate the process and procedures involved in identifying, reporting, escalating, managing, and resolving incidents. The incident management policy should follow the phases of incident response as described in the appropriate incident management framework or standard.
• The incident management policy may also include or combine elements of an incident response plan and supporting operational processes:
  • steps to handle, escalate, and declare incidents
  • triggers to establish an incident response team or incident management team
  • forms, tools, and templates to be used to manage the incident
  • playbooks for specific incidents
  • workflow diagrams to help articulate processes.
• Communications: During an incident it is important that communication is clear, accurate and deliberate. The incident management policy should outline processes and procedures for communications during an incident. This may include communication strategies, key themes, and messages to be developed for internal and external audiences.

Communication strategies for incidents with impacts on the community should align with the Queensland Government Cyber Security Hazard Plan, and Queensland Government Crisis Communications Plan

• Training and exercises: The incident management policy should clearly articulate the training and exercising requirements necessary to ensure the plan is understood. This is also necessary to determine that the plan can be applied effectively. It may be helpful to include a statement on the training level to be maintained by all users and the incident response team or incident management team members.

Developing playbooks

Incident management policies and incident response plans should provide straightforward steps with minimum ambiguity, but it would be impractical for a single policy document to outline how to manage all potential security incidents. For this reason, playbooks should be developed to outline how to respond to specific security incidents. Playbooks enable an entity to respond to and manage specific attacks.

Playbooks are specific to an entity’s technology stack, and they are often created for the most common and/or destructive types of incidents and organisation may face (examples below).

• malware
• phishing
• ransomware
• disruption of service
• data breach
• credential leak
• account take-over
• remote access.

Incident response plans and playbooks are not published publicly. The Queensland Government Cyber Security Unit (QGCSU) share collateral through its communities of practice. The QGCSU can provide examples of specific playbooks for entity review and adaptation on request if they are not members of the communities of practice.

Developing a communications plan

Incident management policies should include a communication plan as this will enable an entity to convey accurate and timely messages to desired audiences during an incident. Effective communication in a crisis will help to support recovery, manage harm, and help to protect or restore an entity’s reputation.

The communication plan should include plans for internal and external communications during an incident. Internal communications should outline the processes and procedures for communicating in an incident and include:

• how incidents are reported
• how contact lists are developed and checked
• how to conduct out of hours communications
• the process to conduct internal briefings to executive and ministerial leadership
• templates to be used for internal communications.

External communication plans should outline how communication strategies, key themes, and messages will be developed for external audiences. This should include:

• an outline of the process of how external messages are drafted, approved, and released
• a list of approved entity spokespersons
• templates for external communications
• processes to report to regulatory bodies (if applicable).

The QGCSU has developed a communications toolkit to assist entities in developing communication products during an incident. The toolkit is available upon request, and outlines the key considerations when drafting messages and adaptable templates for:

• outage messages
• holding lines
• media releases
• website updates
• frequently asked questions.

Exercising and applying lessons learnt

Once established, the incident management policy should be subject to ongoing review and exercised to ensure it is understood and continues to be applied effectively. Lessons identified from exercises should be incorporated to any reviews of the plan. Lessons should always be captured from real life incidents to support incident management policy improvement.

Paying special attention to any operational elements, incident management policies should be reviewed and exercised annually, or following:

• key staff changes
• organisational changes
• key legislative or policy changes
• an incident or medium to high impact
• identification of any issues.

PPOSTTE Model

The PPOSTTE model can assist in reflecting on key elements of the cyber security incident response. This model helps entities codify captured observations related to incidents or exercises:

• People: roles, responsibilities, accountabilities, skills
• Process: plans, policies, procedures, protocols, processes, templates, arrangements
• Organisation: structures, culture, jurisdictional arrangements
• Support: infrastructure, facilities, maintenance
• Technology: equipment, systems, standards, security, inter-operability
• Training: qualifications/skill levels, identification of required courses
• Exercise management: exercise development, structure, management, conduct.

Post incident review

Following any incident a post incident review should be undertaken to identify lessons and learn from them. This should be a complete summary and review of all actions and decisions made during the incident response process. The post incident review should be completed as soon as viable after the closing of the incident to ensure information is not lost.

The development of the post incident review should be a collaborative process that includes the input of as many of the stakeholders including senior management as possible, this ensures the report includes a variety of viewpoints and covers various disciplines.

The output of the post incident review should include specific and actionable changes to existing processes, procedures, ICT, systems, policies to increase efficiency in future incident response incidents.

A post incident review template is located at Appendix B.

Queensland Government Insurance Fund

The Queensland Government Insurance Fund (QGIF) is a self-insurance scheme for applicable Queensland Government entities that provides coverage inclusive of property and general liability. Local governments and government-owned corporations are not eligible for QGIF and should have separate insurance arrangements in place.

QGIF’s policy includes cover for cyber-related events which cause loss or damage to the entity’s IT systems. It also covers amounts an entity may be liable to pay to third parties because of a cyber event or data breach.

The QGCSU work with applicable reporting entities to do this, but all entities should:

• contact qgif@qgif.qld.gov.au to check for coverage by the QGIF scheme
• ensure relevant entity staff are aware of QGIF arrangements and contacts
• ensure incident response and legal processes consider early notification of breaches to QGIF and potential for making a QGIF claim.

Appendix A - Policy checklist

The policy checklist aims to help entities thoroughly plan and manage incidents. It provides tasks and activities which need to be completed in each of the information security event and incident management phases.

Download - Policy checklist (DOCX, 1.1 MB)

Appendix B - Post incident review template

The following template aims to help entities complete their post incident review.

The review should provide a comprehensive summary of all actions and decisions made during the incident response.

The post incident review should include specific and actionable changes to existing processes, procedures, ICT, systems, and policies to increase efficiency in future incident response incidents.

Download - Post incident review checklist (DOCX, 1.1 MB)