Incident management

The official definition of Incident Response is an organised approach to addressing and managing a security incident breach or attack and its aftermath.
The objective is simple - to limit damage and reduce recovery time and costs.
While it sounds like a straightforward objective, in a modern enterprise, it is a complex activity involving multiple teams, technical and business alike.

DORA specify several requirements:

• Identify incidents using early warning indicators
• Establish incident identification, categorisation and types of classification, ensuring their priority aligned services severity.
• Define monitoring and escalation procedures
• Assign roles and responsibilities to be activated for different incident types and scenarios
• Have relevant communication plans in place
• Ensure incidents are:
  
  • a) reported to the appropriate management level
  • b) trends are analysed
  • c) the root cause analysis is performed
  • d) with remedial action taken

All above aims to mitigate impacts and ensure that services become operational and secure in a timely manner.

Classification of ICT-related incidents and cyber threats is a starting point to assess:

• The number and relevance of clients (users) or financial counterparts affected by an incident
• The duration of the incident, including the service downtime
• The geographical spread, particularly if it affects more than two EU countries
• The data losses
• The economic impact, and
• The criticality of the services affected

The criteria require an organisation to have adequate asset management processes linked with company-wide ICT risk management. Without such processes, it will be practically impossible to identify incidents, prioritise the most critical ones and mitigate their impact efficiently.
The asset management, ideally as a single source of truth for the whole organisation, should include detailed documentation for asset identification, criticality criteria, dependencies and owners, among others. The process should cover any third-party suppliers and associated service providers. The asset owner's responsibilities vary from ensuring that the asset is correctly classified, to the day-to-day maintenance of the identified controls, that access controls are defined and periodically reviewed, and that vulnerabilities are identified and patched promptly.

The communication processes, internal reporting and root cause analysis, engagement with clients, partners, extended teams, suppliers and media, as well as reporting to regulators, are other challenges to address.
The notification about major ICT incidents must be submitted to the relevant competent authority within the time limits and include:

• An initial notification - as soon as practical, or without undue delay, as the regulation requires. For the avoidance of doubt, it is the end of the business day.
• An intermediate report, as soon as the status of the original incident has changed - no later than 1 week or the handling of the major ICT-related incident has changed based on new information available.
• A final report, when the root cause analysis has been completed, regardless of whether or not mitigation measures have already been implemented, and when the actual impact figures are available to replace estimates. No later than one month.

An organisation should expect all necessary feedback from the competent authorities, in particular, to discuss remedies at the entity's level or ways to minimise adverse impact across sectors.

P.S.
ESAs, ECB and ENISA will develop common technical standards, specifying the criteria and materiality thresholds for determining major ICT-related incidents, as well as reporting structure.
Stay tuned, but meanwhile, please check our reviews here and contact us to discuss how to manage incidents efficiently and if you want to outsource the reporting obligations.