Free ebook: NIS2 ready using ISO 27001 best practices
Download ebook

Learn more about the connected frameworks

14 §
KyberTL

Poikkeamasta ja kyberuhkasta ilmoittaminen muulle kuin viranomaiselle

23.2
NIS2

Threat notifications to recipients of services

4.2.3
NSM ICT-SP

Inform relevant stakeholders

RS.CO-3
CyFun

Information is shared consistent with response plans.

Other tasks from the same security theme

The step-by-step process of notification of incidents to the authorities

Critical
High
Normal
Low

The organization informs the authority defined in the legislation (CSIRT) without delay about disturbances that have significantly affected the provision of its services. 

A disturbance is significant when at least one of the following occurs:

  • disruption may cause serious disruption in the operation of services or serious financial losses for the service provider
  • disruption may cause significant material or immaterial damage to related people or other organizations

Notifications are to be done step by step according to the descriptions below. In addition, while the disruption is ongoing, the organization must deliver the status updates requested by the authority.

Early warning (at the latest within 24 hours of detecting the disruption)

  • is the cause suspected to be illegal activities
  • can the disruption have effects on other countries

More detailed notification of disruption (within 72 hours of the disruption at the latest detection)

  • previous information is updated
  • the current assessment of the disturbance, its severity and effects is given
  • possible evidence of the leakage is listed

Final report (at the latest within 1 month of the incident report)

  • a detailed description of the incident, including its severity and effects
  • type of threat or root cause that likely triggered the event
  • applied and ongoing mitigation measures
  • potential impact on other countries
23.1: Incident notifications to CSIRT and recipients of services
NIS2
Article 19: Reporting of major ICT-related incidents and voluntary notification of significant cyber threats
DORA
11 §: Poikkeamailmoitukset viranomaiselle
KyberTL
12 §: Poikkeamaa koskeva väliraportti
KyberTL
13 §: Poikkeamaa koskeva loppuraportti
KyberTL

Treatment process and documentation of occurred security incidents

Critical
High
Normal
Low

All security incidents are addressed in a consistent manner to improve security based on what has happened.

In the incident treatment process:

  • the reported incident is confirmed (or found unnecessary to record)
  • the type and cause of incident is documented
  • the risks associated with the incident are documented
  • the risks are re-evaluated and treated if that is necessary after the incident
  • risk mitigation measures or a decision their acceptance is documented
  • people who need to be informed of the results of the incident treatment are identified (including external ones)
  • possible need for a post-incident analysis is determined
12. Transparent information, communication and modalities for the exercise of the rights of the data subject
GDPR
32. Security of processing
GDPR
16.1.5: Response to information security incidents
ISO27 Full
T06: Turvallisuuspoikkeamien hallinta
Katakri
6.4: Menettelytavat virhe- ja ongelmatilanteissa
Self-monitoring

Designation of an incident management team

Critical
High
Normal
Low

The organization shall ensure that clear persons are assigned to incident management responsibilities, e.g. handling the first response for incidents.

Incident management personnel need to be instructed and trained to understand the organization's priorities in dealing with security incidents.

16.1.2: Reporting information security events
ISO27 Full
16.1.3: Reporting information security weaknesses
ISO27 Full
ID.RA-3: Threat identification
NIST
RS.CO-1: Personnel roles
NIST
5.25: Assessment and decision on information security events
ISO27k1 Full

Personnel guidelines for reporting security incidents

Critical
High
Normal
Low

A process for reporting incidents is maintained to help staff report incidents efficiently and consistently.

Things to report as an incident include e.g.:

  • unauthorized access to data / premises
  • action against security guidelines
  • suspected security issue (e.g. phishing, malware infection)
  • data system outage
  • accidental or intentional destruction / alteration of data
  • lost or stolen device
  • compromised password
  • lost physical identifier (e.g. keychain, smart card, smart sticker)
  • suspected security weakness (e.g. on utilized data system or other procedures)

The personnel guidelines emphasize the obligation to report security incidents as soon as possible in accordance with the agreed process. The instructions also describe other operations in the event of an incident (e.g. recording seen error messages and other details).

24. Responsibility of the controller
GDPR
16.1.2: Reporting information security events
ISO27 Full
16.1.3: Reporting information security weaknesses
ISO27 Full
T06: Turvallisuuspoikkeamien hallinta
Katakri
6.4: Menettelytavat virhe- ja ongelmatilanteissa
Self-monitoring

Communication in the event of an incident and preperations

Critical
High
Normal
Low

Viranomaisen on viipymättä tiedotettava niille, jotka hyödyntävät sen tietoaineistoja, jos viranoman tietojenhallintaan kohdistuu häiriö, joka estää tai uhkaa estää tietoaineistojen saatavuuden. Tiedotuksessa on annettava seuraavat tiedot:

a) Häiriön tai sen uhan arvioitu kesto.

b) Mahdolliset korvaavat tavat hyödyntää viranomaisen tietoaineistoja, jos sellaisia on.

c) Häiriön tai uhan päättyessä.

Viranomaisen on noudatettava digitaalisten palvelujen ja muiden sähköisten tiedonsiirtomenetelmien käyttökatkoista tiedottamisesta yleisölle annettuja ohjeita, kuten ne on säädetty digitaalisten palvelujen tarjoamisesta annetun lain (306/2019) 4 §:n 2 momentissa.

13 a §: Häiriötilanteista tiedottaminen ja varautuminen häiriötilanteisiin
TiHL
2.8: Häiriötilanteista tiedottaminen
TiHL: Tietoturva

Reporting of major incidents to competent authorities

Critical
High
Normal
Low

In case of major incidents, the organisation must report them to the authorities defined in their national application of DORA. Reporting of major incidents should include:

  1. First notification
  2. Intermediate report (as status of the incident changes)
  3. Final report when root cause analysis is done

When an incident has an impact of financial interest of clients, they must be informed as soon as possible with needed information about actions to mitigate the incident. In case of cyber threats clients should be informed, if they might be affected, with protection measures they should consider doing.

The relevant competent authorities are defined in Article 46 of DORA

Article 19: Reporting of major ICT-related incidents and voluntary notification of significant cyber threats
DORA

Communication about information security threats and protective measures affecting users of the services

Critical
High
Normal
Low

When users of the organization's services are potentially exposed to a significant information security threat, the organization must communicate this to them, including all possible remedial measures that users can take themselves to protect themselves against the threat.

When necessary for clarity of communication, the organization must include in its communication also more general information about the related information security threat.

23.2: Threat notifications to recipients of services
NIS2
14 §: Poikkeamasta ja kyberuhkasta ilmoittaminen muulle kuin viranomaiselle
KyberTL
RS.CO-3: Information is shared consistent with response plans.
CyFun
4.2.3: Inform relevant stakeholders
NSM ICT-SP

Incident notifications for users of own services

Critical
High
Normal
Low

If it is appropriate from the point of view of the service provided by the organization, the organization will notify the users of its services without delay of significant disruptions that are likely to negatively affect the delivery of the services in question. 

A disruption is significant when at least one of the following occurs:

  • disruption can cause a serious disruption in the operation of services or serious financial losses for the service provider
  • disruption can cause significant material or non-material damage to related people or other organizations
23.1: Incident notifications to CSIRT and recipients of services
NIS2
14 §: Poikkeamasta ja kyberuhkasta ilmoittaminen muulle kuin viranomaiselle
KyberTL
4.2.3: Inform relevant stakeholders
NSM ICT-SP

Regular practice of security incident situations

Critical
High
Normal
Low

The organization should regularly, at least once a year, practice potential disruption or attack situations.

The exercise can focus either on developing disturbance detection, response or management, or all of these.

Documentation of the implementation of exercises and observations must be maintained.

36: Häiriötilanteiden säännöllinen harjoittelu
Sec overview
3.4.5: Test the organisation´s routines for detection and preparedness
NSM ICT-SP
4.1.6: Test and rehearse the plans regularly so that they are established
NSM ICT-SP

Reporting data security incidents to the authorities

Critical
High
Normal
Low

The organization must have a procedure for reporting disturbances, attacks and violations to the authorities. For example:

  • Police
  • Office of the Data Protection Commissioner
  • Cyber Security Center
35: Häiriöiden ilmoittaminen viranomaisille
Sec overview

Definition of tolerable outages

Critical
High
Normal
Low

For each identified critical function, the organization should define how long an interruption can be tolerated without disrupting the organization's operations.

The definition must take into account:

  • Legal requirements related to the availability of the organization's systems, registers and services
  • Requirements of own operations and stakeholders
27: Siedettävien toimintakatkoksien määrittely
Sec overview

Managing evidence information for information security incidents

Critical
High
Normal
Low

Organization must create processes that identify, collect and store relevant evidence information related to information security incidents. The evidence may need to have been collected in a way that can be accepted in relevant courts or other similar disciplinary bodies.

Regarding the evidence material, it should be possible to demonstrate e.g.:

  • the records are complete and not altered in any way
  • copies of electronic evidence are likely to be identical to the originals
  • the data system from which the evidence was collected was functioning properly at the time of collection

Certification or other assurances of the competency of related personnel and tools may additionally be considered to establish more evidentiary value.

5.28: Collection of evidence
ISO27k1 Full
6.2b: Häiriöiden hallinta ja menettelyt ongelmatilanteissa
Tietoturvasuunnitelma
4.3.3: Log all activities, results and relevant decisions
NSM ICT-SP

Incident containing measures

Critical
High
Normal
Low

The organization shall establish means to limit the impact of the incident to a minimum. The means should correspond to the plans made and include:

  • Preparations for incidents
  • Analyzing of the incident
  • Containment of the incident
  • Destruction of the incident
  • Starting the recovery measures
RS.MI-1: Incident containment
NIST
Article 17: ICT-related incident management process
DORA
RS.MI-1: Incidents are contained.
CyFun
4.3.2: Determine whether the incident is under control and take the necessary reactive measures
NSM ICT-SP

Detection process testing and compliance

Critical
High
Normal
Low

Detection processes and procedures are maintained and tested to ensure awareness of anomalous events. Detection activities must comply with all relevant requirements.

DE.DP-2: Detection activities
NIST
TEK-13: Poikkeamien havainnointikyky ja toipuminen
Julkri
CC7.2: Monitoring of system components for anomalies
SOC 2
DE.DP-2: Detection activities comply with all applicable requirements.
CyFun

Defining threshold for cyber security breach

Critical
High
Normal
Low

The organization must define the threshold at which a security incident becomes a cyber security breach.

DE.AE-5: Incident alert thresholds
NIST
RESPONSE-2: Analyze Cybersecurity Events and Declare Incidents
C2M2: MIL1
Article 17: ICT-related incident management process
DORA
DE.AE-5: Incident alert thresholds are established.
CyFun

Identification and monitoring of event sources

Critical
High
Normal
Low

The organization shall determine what security events it monitors and in what ways.

Security events should be monitored from a variety of sources to identify important potential incidents that require a response. Information can be obtained e.g. directly from the management system, external partners, or logs generated by the organization’s equipment.

Examples of security incidents that can be monitored include:

  1. Slow server performance
  2. Recurring login errors
  3. Unknown login attempts
  4. Abnormal network traffic
  5. Out of storage
  6. Changes in code projects
  7. Configuration changes in the firewall
  8. Access changes to critical systems / servers / databases
  9. Large database downloads
  10. Unauthorized software installations on endpoint devices
  11. Traffic from IP addresses known to be malicious
DE.AE-3: Event data
NIST
TEK-13: Poikkeamien havainnointikyky ja toipuminen
Julkri
RESPONSE-1: Detect Cybersecurity Events
C2M2: MIL1
DE.AE-3: Event data are collected and correlated from multiple sources and sensors.
CyFun

Processes for reporting information security events related to offered cloud services

Critical
High
Normal
Low

When offering cloud services, the organisation needs to have planned processes or procedures for:

  • how the cloud service customer reports an information security event to the organisation
  • how the organisation reports information security events to cloud service customers
  • how the cloud service customer can track the status of a previously reported information security event
ID.RA-3: Threat identification
NIST
DE.DP-4: Event detection
NIST
RS.CO-3: Information sharing
NIST
RC.CO-1: Public relations
NIST
16: Information security incident management
ISO 27017

Defining cyber security metrics for cyber security breaches

Critical
High
Normal
Low

The organization has defined metrics that can be monitored and are related to cyber security incident management. At its best, good metrics help detect weaknesses in incident detection.

Possible metrics include:

  • Number of security incidents and relationship to disruptions
  • Number of disruptions by service, department, severity or type provided
  • Time required for incident identification, investigation and handling
  • Deviations from documented practices
RESPONSE-2: Analyze Cybersecurity Events and Declare Incidents
C2M2: MIL1
Article 17: ICT-related incident management process
DORA

The first level response process to security incidents

Critical
High
Normal
Low

The organization has defined a process and the team involved in responding promptly to security incidents and deciding on the appropriate actions.

The first level response process includes at least:

  • effectively seeking to confirm the identified incident
  • deciding on the need for immediate response
16.1.4: Assessment of and decision on information security events
ISO27 Full
6.4: Menettelytavat virhe- ja ongelmatilanteissa
Self-monitoring
DE.AE-4: Impact of events
NIST
RS.RP: Response Planning
NIST
RS.RP-1: Incident response plan
NIST

Reporting security breach to authorities

Critical
High
Normal
Low

The organization must have a process for reporting a security breach that has occurred or is suspected of endangering internationally classified information to the competent security authority.

The organization must also have guidelines and procedures for detecting and informing of security breaches that have compromised classified information within the organization and to whom the security breach or suspicion thereof should be sent. inform. In addition, it must be clear what kinds of data security deviations require contacting the authorities.

Security classified information is considered compromised when it has been revealed or could have been revealed to outsiders as a result of a data security incident. Several data owners (e.g. the EU) as well as valid authority approvals require immediate notification of deviations or suspicions that endanger classified information.

T-07: TURVALLISUUSPOIKKEAMIEN HALLINTA
Katakri 2020

Consideration of classified information in the incident management

Critical
High
Normal
Low

Incident management must also take into account:

  • Protection of classified data in emergency and disruption situations
  • Classified information has sufficient security measures to protect against unauthorized access to the data and its integrity and usability
  • Classified information must be protected from technical and physical damage.

The organization must be sure that the information or system being processed is protected from physical damage such as fire, water damage or vandalism in emergency or disruption situations, or unauthorized intrusion and physical damage caused using electronic methods, such as equipment breakage. Information or the system must be protected with appropriate, but appropriate actions based on the risk assessment.

T-06: TOIMINTAHÄIRIÖT JA POIKKEUSTILANTEET
Katakri 2020

Sufficient resourcing of ICT-environment monitoring

Critical
High
Normal
Low

The organisation must devote sufficient resources for monitoring user activity, anomalies in the ICT-environment, and cyber attacks.

By monitoring organisation should recognize anomalies and incidents from the baseline operations.


Article 10: Detection
DORA

Classification of incidents

Critical
High
Normal
Low

Organisations should conduct incident classification and impact assesment based on the following criteria:

  • Number of affected parties (clients, other organisations) and if possible the number of transactions that were affected.
  • Reputational impact
  • Duration and downtime caused by the incident
  • Geopgraphical spread of the affects
  • Possible data losses in relation to CIA values
  • Criticality of the services affected
  • Economic impact
Article 18: Classification of ICT-related incidents and cyber threats
DORA
4.2.1: Review log data and collect relevant data on the incident to create a good basis for making decisions
NSM ICT-SP
4.2.2: Determine the severity level of the incident
NSM ICT-SP

Process for categorization of security incidents

Critical
High
Normal
Low

Organisation should have a procedure for categorizing security incidents during processing. The incident should be categorized to at least the following categories:

  • Personnel
  • Physical
  • Cyber

The incident should then be qualified based on it's effects for example into:

  • Not security relevant
  • Observation
  • Suggested improvement
  • Vulnerability
  • Security incident

The incidents should then be prioritized based on the severity of the incident.

1.6.2: Management of reported events
TISAX

Internal communication in a incident situation

Critical
High
Normal
Low

The organisation should have clear communication channels for event reporting:

  • Establish and maintain adequate communication channels for security event reporters, ensuring that:
  • A common point of contact for reporting events is identified and communicated to all relevant parties.
  • Different reporting channels are available based on the perceived severity of events, including real-time communication options for significant emergencies and asynchronous methods (e.g., tickets, email) for less urgent matters.

Organisation should also consider the possibility of external reporting. This could mean having a system to handle security event reports from external parties, including:

  • An externally accessible and well-communicated method for reporting security events.
  • Defined procedures for responding to and addressing security event reports from external sources.

The organisation should also ensure that the mechanisms and information for reporting incidents are easily accessible to all relevant reporters and establish a feedback procedure to provide timely responses and updates to those who report security events, ensuring they are informed of the outcomes and any necessary follow-up actions.


1.6.1: Reporting of security events
TISAX

Defining security events and incidents

Critical
High
Normal
Low

Organisation must develop a clear, comprehensive definition of what constitutes a reportable security event or observation, ensuring it covers the following categories:

  • Personnel misconduct or misbehavior.
  • Intrusion, theft, unauthorized access to security zones, and vulnerabilities in security zones.
  • Cybersecurity incidents such as vulnerabilities in IT systems, and detected successful or unsuccessful cyber-attacks.
  • Supplier and partner incidents that could negatively impact the security of the organization.

Organisation must have a defined procedure for reporting of incidents and it should be communicated to the personnel:

  • Design and implement effective reporting mechanisms tailored to perceived risks.
  • Ensure these mechanisms are well communicated and accessible to all employees, stakeholders, and relevant parties to facilitate timely and accurate reporting of security events.
  • Conduct training sessions and awareness programs to ensure that all relevant employees and stakeholders understand the definition of reportable security events and are familiar with the reporting mechanisms.
1.6.1: Reporting of security events
TISAX

Ensuring the safe failure of the critical systems in a network loss

Critical
High
Normal
Low

In case of a connection loss or a fault in the network systems, such as:

  • Failure in the organization's firewall systems
  • Network loss
  • Destruction of a physical component

The organization should ensure that their critical systems fail safely, to reduce further damage.

PR.AC-5: Network integrity (network segregation, network segmentation… ) is protected.
CyFun

Communicating with relevant parties after an incident, including CERTs and NSM NCSC

Critical
High
Normal
Low

The organization has defined procedures for communicating with relevant authorities and parties when an incident occurs. These parties include, for example, sector-specific computer emergency response teams and the NSM NCSC.

4.3.6: Perform necessary activities after the incident
NSM ICT-SP

Developing and executing a recovery plan

Critical
High
Normal
Low

The organization should have a defined and well-documented recovery plan. The recovery plan should be able to be initiated during or after an incident. Recovery actions and measures will vary from incident to incident, for example, the type of incident can affect the actions taken. These actions could include:

  • Reactivating redundant resources lost or damaged during the incident
  • Reinstalling hardware and software on affected components
  • Restoring configuration settings, including any necessary adjustments
  • Restoring services halted during the incident

The organization should adopt a 'build back better' mindset when rebuilding ICT systems. This means that systems should be rebuilt to a better state than they were before the incident.

4.3.4: Launch recovery plan during or after the incident
NSM ICT-SP

Documenting incident activities by establishing a response timeline

Critical
High
Normal
Low

The organization should establish clear processes for building a timeline whenever an incident occurs. This timeline should include both the organization's actions and the threat actor's activities. The timeline should encompass:

  • When and how the initial breach occurred
  • The threat actor's movements within the ICT system (e.g., possible privilege escalation)
  • Key decisions made by the organization during the response phase
  • Communication between relevant parties

This aids the organization in understanding the full scope of the incident and improving responses in future events.

4.3.3: Log all activities, results and relevant decisions
NSM ICT-SP

Enriching incident information to ensure an effective response

Critical
High
Normal
Low

The organization should have a clear process for enriching incident information to ensure an effective response. This process should include continuously updating event data, monitoring situational awareness, and collecting information from multiple sources. Enriching incident information should help the organization manage incidents more effectively.


4.3.3: Log all activities, results and relevant decisions
NSM ICT-SP

Identifying the impact on business processes

Critical
High
Normal
Low

Identify the extent and impact of the incident on business processes to understand how operations may be disrupted. This assessment should include a thorough evaluation of the effects on underlying ICT functions. Also, it should be examined how the incident impacts ICT services, including cloud-based applications and internal systems, as well as the various ICT systems that support business activities.

4.3.1: Identify extent and impact on business processes
NSM ICT-SP

Creating and maintaining incident response plans

Critical
High
Normal
Low

The organization should create and maintain incident response plans. The response plans should include at least:

  • Incident or the type of incident for which the plan has been made
  • Goal for plan
  • Responsible persons and related stakeholders and contact information
  • Planned immediate actions
  • Planned next steps
4.1.1: Establish plans for incident management
NSM ICT-SP

Including suppliers in incident management

Critical
High
Normal
Low

Organization should include suppliers and other relevant third parties in its incident management process and planning with means such as:

  • Define and implement rules, roles and protocols for reporting incident response and recovery activities between the organization and its suppliers
  • Include critical suppliers in regular incident response exercises and simulations
  • Establish and coordinate crisis communication methods and protocols between the organization and its critical suppliers
  • Conduct collaborative lessons learned sessions with critical suppliers after incidents to improve joint response capabilities and refine processes for future incidents
No items found.

Incident response documentation and integrity

Critical
High
Normal
Low

Organization enforces documentation policies for each incident investigation and response process:

  • Require each incident responder or investigator, including system administrators and cybersecurity personnel, to record their actions during the process. Ensure that these records are made immutable to preserve their integrity for future analysis and audits.
  • Assign the incident lead the responsibility to document the incident in detail, capturing all actions, findings, and decisions made throughout the incident response process.
  • Ensure the incident lead is accountable for maintaining the integrity of all documentation and preserving the sources of information being reported, preventing tampering or loss of data.
No items found.

Public communication on incident recovery measures

Critical
High
Normal
Low

In case of an incident the organization implements recovery measures defined in its incident recovery plan. The measures are implemented and communicated to the public to:

  • Manage the public view and control the narrative
  • Mitigate the impact of the incident on the organization

The organization should explain the steps being taken to recover from the incident and to prevent a recurrence.

No items found.

Defining threshold for incident recovery measures

Critical
High
Normal
Low

Organization defines criteria for initiating incident recovery measures on incidents. The occurred incident is evaluated against these criteria, and determined whether the incident recovery process shall be initiated, by at least these measures:

  • Apply incident recovery criteria to the known and assumed characteristics of an incident to evaluate whether incident recovery processes should be initiated, considering factors such as severity, impact, and scope
  • Assess the potential operational disruption caused by incident recovery activities and develop strategies to minimize impact on ongoing business operations during the recovery phase
  • Establish clear criteria for prioritizing incident recovery efforts based on the nature of the incident, including data sensitivity, affected systems, and business continuity requirements

Document the decision-making process for initiating recovery actions and ensure that it is communicated to relevant stakeholders for transparency and alignment.

No items found.

Consideration of environmental threats in risk and incident management

Critical
High
Normal
Low

The organization should take into account environmental threats that may affect the usability of systems as part of the risk assessment process and also as part of the information security incident process.

Environmental threats include, for example:

  • Unfavorable weather
  • Failure in environmental management systems
  • Power spikes in electricity distribution
  • Fires
  • Water damage


A1.2: Recovery of infrastructure according to objectives
SOC 2

Forensic investigation of incidents

Critical
High
Normal
Low

After a disturbance, a forensic examination must be carried out on the malicious code or other remnants of the disturbance. A safe investigation in a closed environment can open up the causes, goals, and motives of the incident. This helps the organization fix potential security vulnerabilities, prepare for similar incidents, and identify or profile a potential attacker.

RS.AN-3: Forensics
NIST
6.8: Asiakas- ja potilastietojärjestelmien pääsynhallinnan ja käytön seurannan käytännöt
Tietoturvasuunnitelma
RS.AN-3: Forensics are performed.
CyFun
4.3.6: Perform necessary activities after the incident
NSM ICT-SP

Ensuring sorting of cyber security events

Critical
High
Normal
Low

The organization shall define procedures for clearly sorting detected security events. Sorting must enable the prioritizing of events according to severity and potential impact.

Sorting is intended to enhance the investigation and evaluation of security events so that, for example, a response to a disruption can be initiated quickly.

Procedures can consist of common processes, technical tools, or algorithms that utilize machine learning. Procedures need to be reviewed regularly to ensure that they work and are appropriate for their needs.

DE.AE-2: Analyze detected events
NIST
RESPONSE-2: Analyze Cybersecurity Events and Declare Incidents
C2M2: MIL1
Article 17: ICT-related incident management process
DORA
DE.AE-2: Detected events are analysed to understand attack targets and methods.
CyFun

Follow-up analysis for security incidents

Critical
High
Normal
Low

If it is difficult to identify the source of a security incident based on the primary treatment, a separate follow-up analysis is performed for the incident, in which the root cause is sought to be identified.

16.1.6: Learning from information security incidents
ISO27 Full
6.4: Menettelytavat virhe- ja ongelmatilanteissa
Self-monitoring
ID.RA-4: Impacts on business
NIST
DE.DP-5: Detection processes improvment
NIST
RS.AN-2: The impact of the incident
NIST

Regular periodic analysis and learning of incidents

Critical
High
Normal
Low

The knowledge gained from analyzing and resolving security incidents should be used to reduce the likelihood of future incidents and their impact.

The organization regularly analyzes incidents as a whole. This process examines the type, amount and cost of incidents with the aim of identifying recurrent and significant incidents that need more action.

If recurrent incidents requiring response are identified, based on them:

  • new management tasks are created or current ones expanded
  • security guidelines in this area are refined or extended
  • a case example of the incident is created that is used to train staff to respond to or avoid similar incidents
16.1.6: Learning from information security incidents
ISO27 Full
PR.IP-7: Protection processes
NIST
PR.IP-8: Protection effectiveness
NIST
DE.DP-5: Detection processes improvment
NIST
RS.AN-2: The impact of the incident
NIST

Communicating the results of cyber security incident analysis

Critical
High
Normal
Low

The organization has defined procedures to ensure that the original reporter and other personnel involved in the incident are informed of the outcome of the incident management.

Linked personnel can be documented on an optional field on the incident documentation template.

16.1.6: Learning from information security incidents
ISO27 Full
PR.IP-8: Protection effectiveness
NIST
DE.DP-4: Event detection
NIST
5.27: Learning from information security incidents
ISO27k1 Full
CC2.2: Internal communication of information
SOC 2

Whistle blowing -system

Critical
High
Normal
Low

Staff have a whistle blowing system that allows them to report breaches of security rules or procedures anonymously.

No items found.

Voluntary notifications of security incidents

Critical
High
Normal
Low

An organization may have a process for voluntarily informing information certain security incidents, cyber threats or near-misses to a supervisory authority.

Voluntary notifications refers to notifications for other than significant incidents, which are mandatory by the NIS2 directive.

15 §: Vapaaehtoinen ilmoittaminen
KyberTL