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

Learn more about the connected frameworks

11.2.2
ISO27 Full

Supporting utilities

12.1.3
ISO27 Full

Capacity management

3.2.1
NSM ICT-SP

Determine a strategy and guidelines for security monitoring

7.11
ISO27k1 Full

Supporting utilities

8.6
ISO27k1 Full

Capacity management

A1.1
SOC 2

Evaluation of current processing capacity

PR.DS-4
NIST

Availability

PR.DS-4
CyFun

Adequate capacity to ensure availability is maintained.

TEK-22
Julkri

Tietojärjestelmien saatavuus

Other tasks from the same security theme

The goals of threat intelligence and the collection of information related to information security threats

Critical
High
Normal
Low

Organization carries out threat intelligence by gathering information about information security threats related to its operations and how to protect against them. The goal is to increase awareness of the threat environment, so that own security level can be better evaluated and adequate control measures implemented.

When collecting threat intelligence, all three levels must be taken into account:

  • strategic threat intelligence (e.g. information on the growing types of attackers and attacks)
  • tactical threat intelligence (e.g. information about tools and technologies used in attacks)
  • operational threat intelligence (e.g. details of specific attacks)

Principles related to threat intelligence should include:

  • setting targets for threat intelligence
  • identification, verification and selection of information sources used in threat intelligence
  • gathering threat intelligence
  • data processing for analysis (e.g. translation, formatting, compression)
5.7: Threat intelligence
ISO27k1 Full
77: Menettely toimintaympäristön seuraamiseen
Sec overview
Article 13: Learning and evolving
DORA
4.1: Tietojärjestelmien tietoturvallisuus
TiHL: Tietoturva
ID.RA-2: Cyber threat intelligence is received from information sharing forums and sources.
CyFun

Process for managing technical vulnerabilities

Critical
High
Normal
Low

The organization has defined a process for addressing identified technical vulnerabilities.

Some vulnerabilities can be fixed directly, but vulnerabilities that have a significant impact should also be documented as security incidents. Once a vulnerability with significant impacts has been identified:

  • risks related to the vulnerability and the necessary actions are identified (e.g. patching the system or other management tasks)
  • necessary actions are scheduled
  • all actions taken are documented
12.6.1: Management of technical vulnerabilities
ISO27 Full
14.2.1: Secure development policy
ISO27 Full
ID.RA-1: Asset vulnerabilities
NIST
PR.IP-12: Vulnerability management plan
NIST
RS.AN-5: Vulnerability management process
NIST

Regulalry conducting threat-led penetration testing (TLPT)

Critical
High
Normal
Low

Organization has a process for regulalry conducting threat-led penetration testing (TLPT).

TLPT process fills the following requirements:

  1. Frequency: Financial entities are required to conduct advanced TLPT by default every three years.
  2. Scope: Each TLPT must cover several or all critical or important functions of the entity and must be conducted on live production systems that support these functions.
  3. Inclusion of third-party ICT providers: If critical functions are outsourced to third-party ICT service providers, these providers must be included in the TLPT.
  4. Vulnerability mitigation: Entities must (in collaboration with third-party providers and testers) apply effective risk management controls to mitigate potential impacts on data, assets, and operations.
  5. Test reporting: Upon completing the testing, entities must provide a summary of findings and remediation plans to the designated authority.
  6. Tester requirements: Entities must engage testers as specified in the regulations, using external testers periodically (every three tests) unless classified as significant, in which case only external testers must be used.
Article 26: Advanced testing of ICT tools, systems and processes based on TLPT
DORA

Regularly conducting penetration testing with predefined goals and scope

Critical
High
Normal
Low

Penetration testing should have clearly defined goals and scope. The goals may include, e.g., testing continuity plans and capabilities, assessing security controls or identifying security weaknesses. The scope can be defined as follows:

  • - Identify critical parts of the information system that should be prioritized during testing.
  • - Identify individual systems or components that are so vital they must be excluded from testing.

Vital systems or components that could be excluded, e.g., include those essential for maintaining critical organizational services or those unable to withstand the stress of a penetration test.

During the planning phase, it is important to involve relevant stakeholders in advance. This often means informing external system monitoring providers prior to testing, though it may not be necessary to inform users or system management personnel.

Penetration testing should be conducted regularly, at least annually. It should be performed both from outside the organization's network perimeter and from within. Testing from the outside simulates an external attack (black box and white box), while testing from the inside simulates potential threats from compromised clients/servers or malicious insiders (grey box).

The results of penetration tests should always be documented.

3.4.2: Involve relevant stakeholders in advance
NSM ICT-SP
3.4.1: Plan penetration testing with defined goals and scope
NSM ICT-SP
3.4.4: Perform regular penetration testing (at least annually) to identify vulnerabilities
NSM ICT-SP

Monitoring of technical vulnerability communications

Critical
High
Normal
Low

The organization monitors information about technical vulnerabilities of the information systems in use. When relevant technical vulnerabilities are detected, the organization takes action according to the planned operating model.

50: Teknisten haavoittuvuuksien seuranta
Sec overview
THREAT-1: Reduce Cybersecurity Vulnerabilities
C2M2: MIL1
9.3 §: Tietojärjestelmien hankinta ja kehittäminen
KyberTL

Regular analysis and utilization of information related to information security threats

Critical
High
Normal
Low

Organization carries out threat intelligence by analyzing and utilizing collected information about relevant cyber security threats related and corresponding protections.

When analyzing and utilizing the collected threat intelligence information, the following points must be taken into account:

  • analyzing how the threat intelligence information relates to to our own operations
  • analyzing how relevant threat intelligence information is to our operations
  • communicating and sharing information in an understandable form to relevant persons
  • utilizing the findings of threat intelligence to determine the adequacy of technical protections, technologies used and information security testing methods for analysis
5.7: Threat intelligence
ISO27k1 Full
23: Häiriöiden- ja poikkeamienhallintaprosessi
Sec overview
THREAT-2: Respond to Threats and Share Threat Information
C2M2: MIL1
Article 13: Learning and evolving
DORA
3.3.4: Obtain and process threat information from relevant sources
NSM ICT-SP

Maintaining system hardening

Critical
High
Normal
Low

The validity and effectiveness of used hardening is maintained throughout the whole life cycle of the data system.

TEK-10.2: Järjestelmäkovennus - kovennusten varmistaminen koko elinkaaren ajan
Julkri
I-08: VÄHIMMÄISTOIMINTOJEN JA VÄHIMPIEN OIKEUKSIEN PERIAATE – JÄRJESTELMÄKOVENNUS
Katakri 2020

Säännöllinen kattava haavoittuvuusskannaus (TL III)

Critical
High
Normal
Low

Tietojenkäsittely-ympäristön laitteet tarkastetaan kattavasti ohjelmistohaavoittuvuuksien varalta vähintään puolivuosittain ja merkittävien muutosten yhteydessä. Prosessissa on huomioitu seuraavat seikat:

  • Verkko ja sen palvelut, palvelimet sekä verkkoon kytketyt työasemat, kannettavat tietokoneet, tulostimet, mobiililaitteet ja vastaavat tarkastetaan kattavasti vähintään (haavoittuvuusskannaus, CMDB jne.) vuosittain ja aina merkittävien muutosten jälkeen päivitysmenettelyjen korjauskohteiden löytämiseksi.
  • Laitteisto- ja ohjelmistokirjanpidon (ml. CMDB) sekä skannausohjelmiston ajantasaisuudesta ja tietoturvallisuudesta on huolehdittu.

"Merkittäviin muutoksiin" voidaan laskea esim. verkkotopologian muutokset, uusien järjestelmien käyttöönotot ja/tai vanhojen service pack -tason päivitykset sekä palomuurien ja vastaavien suodatussääntöjen merkittävät muutokset.

TEK-19.2: Ohjelmistohaavoittuvuuksien hallinta - TL III
Julkri
I-19: TIETOJENKÄSITTELY-YMPÄRISTÖN SUOJAUS KOKO ELINKAAREN AJAN – OHJELMISTOHAAVOITTUVUUKSIEN HALLINTA
Katakri 2020

Säännöllinen kattava haavoittuvuusskannaus (TL IV)

Critical
High
Normal
Low

Tietojenkäsittely-ympäristön laitteet tarkastetaan kattavasti ohjelmistohaavoittuvuuksien varalta vähintään vuosittain ja merkittävien muutosten yhteydessä. Prosessissa on huomioitu seuraavat seikat:

  • Verkko ja sen palvelut, palvelimet sekä verkkoon kytketyt työasemat, kannettavat tietokoneet, tulostimet, mobiililaitteet ja vastaavat tarkastetaan kattavasti vähintään (haavoittuvuusskannaus, CMDB jne.) vuosittain ja aina merkittävien muutosten jälkeen päivitysmenettelyjen korjauskohteiden löytämiseksi.
  • Laitteisto- ja ohjelmistokirjanpidon (ml. CMDB) sekä skannausohjelmiston ajantasaisuudesta ja tietoturvallisuudesta on huolehdittu.

"Merkittäviin muutoksiin" voidaan laskea esim. verkkotopologian muutokset, uusien järjestelmien käyttöönotot ja/tai vanhojen service pack -tason päivitykset sekä palomuurien ja vastaavien suodatussääntöjen merkittävät muutokset.

TEK-19.1: Ohjelmistohaavoittuvuuksien hallinta
Julkri
I-19: TIETOJENKÄSITTELY-YMPÄRISTÖN SUOJAUS KOKO ELINKAAREN AJAN – OHJELMISTOHAAVOITTUVUUKSIEN HALLINTA
Katakri 2020

Regular testing of the vulnerability management process

Critical
High
Normal
Low

The vulnerability management process is regularly tested at intervals specified by the organization to ensure that it is up-to-date, functional, and effective.

DE.DP-3: Detection processes testing
NIST
TEK-19: Ohjelmistohaavoittuvuuksien hallinta
Julkri
I-19: TIETOJENKÄSITTELY-YMPÄRISTÖN SUOJAUS KOKO ELINKAAREN AJAN – OHJELMISTOHAAVOITTUVUUKSIEN HALLINTA
Katakri 2020
DE.DP-3: Detection processes are tested.
CyFun
RS.AN-5: Processes are established to receive, analyse, and respond to vulnerabilities disclosed to the organization from internal and external sources.
CyFun

Hardening of virtual machines utilized in cloud service offering

Critical
High
Normal
Low

Hardening is the practice of reducing system vulnerability by reducing its attack surface.

When configuring virtual machines the organization has to make sure the machines are hardened by, for example, only using ports, protocols and services that are needed. There must also be technical security measures like anti-malware and logging enabled for all virtual machines.

CLD 9.5.2: Virtual machine hardening
ISO 27017

Defining metrics related to vulnerability management

Critical
High
Normal
Low

The organization needs to define Monitored Metrics for identifying and correcting vulnerabilities. Meters must be monitored at specified intervals.

No items found.

Prioritization of identified technical vulnerabilities and remediation goals

Critical
High
Normal
Low

The organization must have a clear model for prioritizing identified technical vulnerabilities. The operating model should not be entirely new invention, but should be based on generally accepted practices.

Vulnerabilities should be prioritized based on the risk they pose, the importance of the assets involved, the potential organizational impact, and the urgency (taking into account the CVSS value).

4.1: Tietojärjestelmien tietoturvallisuus
TiHL: Tietoturva
3.1.1: Conduct regular vulnerability assessments
NSM ICT-SP

Automating the handling of technical vulnerabilities

Critical
High
Normal
Low

The organization must develop a process to automate the treatment of technical vulnerabilities.

RS.AN-5: Processes are established to receive, analyse, and respond to vulnerabilities disclosed to the organization from internal and external sources.
CyFun
2.3.1: Establish centrally managed practices for security updates
NSM ICT-SP

Regular penetration testing

Critical
High
Normal
Low

Static scans on code are the first step in detecting risky vulnerabilities. However, once a service has been deployed, it is vulnerable to new types of attacks (e.g., cross-site scripting or authentication issues). These can be identified by penetration testing.

12.6.1: Management of technical vulnerabilities
ISO27 Full
14.2.8: System security testing
ISO27 Full
18.2.3: Technical compliance review
ISO27 Full
DE.CM-8: Vulnerability scans
NIST
5.36: Compliance with policies, rules and standards for information security
ISO27k1 Full

Ohjelmistohaavoittuvuuksien säännöllinen tarkastelu (ST III-II)

Critical
High
Normal
Low

Ohjelmistohaavoittuvuuksien hallitsemiseksi suojaustasoilla III-II toteutetaan seuraavat toimenpiteet:

  • Verkko ja sen palvelut, palvelimet sekä verkkoon kytketyt työasemat, kannettavat tietokoneet ja vastaavat tarkastetaan vähintään (haavoittuvuusskannaus, CMDB, jne.) puolivuosittain ja aina merkittävien muutosten jälkeen päivitysmenettelyjen korjauskohteiden löytämiseksi.
  • Säännöllisesti (esim. kuukausittain) tarkastellaan keskitetyistä päivityksenjakopalveluista päivitysten asentumisen onnistumista.

Merkittäviä muutoksia ovat mm. verkkotopologian muutokset, uusien järjestelmien käyttöönotot, vanhojen järjestelmien merkittävät päivitykset sekä palomuurien ja vastaavien suodatussääntöjen merkittävät muutokset.

I23: Ohjelmistohaavoittuvuuksien hallinta
Katakri

Ohjelmistohaavoittuvuuksien säännöllinen tarkastelu (ST IV)

Critical
High
Normal
Low

Ohjelmistohaavoittuvuuksien hallitsemiseksi suojaustasolla IV toteutetaan seuraavat toimenpiteet:

  • Verkko ja sen palvelut, palvelimet sekä verkkoon kytketyt työasemat, kannettavat tietokoneet ja vastaavat tarkastetaan vähintään (haavoittuvuusskannaus, CMDB, jne.) vuosittain ja aina merkittävien muutosten jälkeen päivitysmenettelyjen korjauskohteiden löytämiseksi.
  • Säännöllisesti (esim. kuukausittain) tarkastellaan keskitetyistä päivityksenjakopalveluista päivitysten asentumisen onnistumista.

Merkittäviä muutoksia ovat mm. verkkotopologian muutokset, uusien järjestelmien käyttöönotot, vanhojen järjestelmien merkittävät päivitykset sekä palomuurien ja vastaavien suodatussääntöjen merkittävät muutokset.

I23: Ohjelmistohaavoittuvuuksien hallinta
Katakri

Selecting and tracking data sources for vulnerability information

Critical
High
Normal
Low

Information sources for software and other technologies have been consciously identified to identify and maintain information about technical vulnerabilities that are relevant to us (e.g. authorities or hardware and software manufacturers). Data sources are evaluated and updated as new useful sources are found.

Vulnerabilities can be found directly in the vendor systems we exploit or in the open source components exploited by many of our systems. It’s important to keep track of multiple sources to get the essential information obtained.

I23: Ohjelmistohaavoittuvuuksien hallinta
Katakri
12.6.1: Management of technical vulnerabilities
ISO27 Full
DE.CM-8: Vulnerability scans
NIST
TEK-19: Ohjelmistohaavoittuvuuksien hallinta
Julkri
8.8: Management of technical vulnerabilities
ISO27k1 Full

Initial treatment of identified technical vulnerabilities

Critical
High
Normal
Low

We have defined the rules for responding to identified vulnerabilities. The rules may include e.g. the following things:

  • who are part of a quick-response team that is ready to respond to vulnerabilities
  • the person locating the vulnerability immediately informs the entire team down the agreed channel
  • the team determines the severity of the vulnerability (low, medium, high) based on predefined criteria
  • the team decides whether to continue processing as a security breach (more urgently) or under general change management
  • the necessary individuals are selected to continue addressing the vulnerability

Vulnerabilities related to high-risk data systems are always of high severity and are addressed first.

12.6.1: Management of technical vulnerabilities
ISO27 Full
ID.RA-1: Asset vulnerabilities
NIST
PR.IP-12: Vulnerability management plan
NIST
RS.AN-5: Vulnerability management process
NIST
RS.MI-3: New vulnerability mitigation
NIST

Regular vulnerability scanning

Critical
High
Normal
Low

The organization regularly conducts a vulnerability scan, which searches for vulnerabilities found on computers, workstations, mobile devices, networks or applications. It is important to scan even after significant changes.

It should be noted that vulnerable source code can be from operating system software, server applications, user applications, as well as from the firmware application as well as from drivers, BIOS and separate management interfaces (e.g. iLo , iDrac). In addition to software errors, vulnerabilities occur from configuration errors and old practices, such as the use of outdated encryption algorithms.

12.6.1: Management of technical vulnerabilities
ISO27 Full
18.2.3: Technical compliance review
ISO27 Full
14.2.8: System security testing
ISO27 Full
6.5: Tietojärjestelmien asennus, ylläpito ja päivitys
Self-monitoring
MWP-02: Automatic file scan by anti-malware software
Cyber Essentials

Anticipating capacity-related problems

Critical
High
Normal
Low

The operation of information systems may depend on certain key resources, such as server capacity, file storage capacity, data processing capacity, monitoring capacity or certain key persons.

In particular, some of these resources may have long delivery times or high costs in certain situations, in which case special attention must be paid to future capacity problems with them.

We monitor the use of key system resources and identify trends, potential security bottlenecks and dependencies on important people.

11.2.2: Supporting utilities
ISO27 Full
12.1.3: Capacity management
ISO27 Full
PR.DS-4: Availability
NIST
TEK-22: Tietojärjestelmien saatavuus
Julkri
8.6: Capacity management
ISO27k1 Full

Authorized users and rules for installing software and libraries

Critical
High
Normal
Low

Unmanaged installations of software on computers can lead to vulnerabilities and security breaches.

The organization should determine what types of software or updates each user can install. The instructions may include e.g. the following guidelines:

  • only specially designated persons may install new software on the devices
  • programs previously designated as secure may be installed by anyone
  • use of certain software may be impossible for everyone
  • existing software updates and security patches are allowed to be installed by anyone
12.6.2: Restrictions on software installation
ISO27 Full
SUM-02: Keeping licensed software up to date
Cyber Essentials
DE.CM-5: Unauthorized mobile code detection
NIST
TEK-17: Muutoshallintamenettelyt
Julkri
8.19: Installation of software on operational systems
ISO27k1 Full

Separation of critical environments

Critical
High
Normal
Low

Isolate technical environments where the consequences can be very damaging.

13.1.3: Segregation in networks
ISO27 Full
PR.AC-5: Network integrity
NIST
8.22: Segregation of networks
ISO27k1 Full
2.3.1: Establish centrally managed practices for security updates
NSM ICT-SP

Personnel support for chosen resilience testing operations

Critical
High
Normal
Low

Organization's resilience testing programme is prepared for providing all the necessary supporting expert work for the chosen resilience testing operations. This may include e.g. performance testing, end-to-end testing, penetration testing or source code reviews.

Related resilience testing operations can e.g. include vulnerability scans, other scanning software use, network security assements, physical security reviews or other kinds of gap analyses.

Article 25: Testing of ICT tools and systems
DORA

TLPT tester requirements

Critical
High
Normal
Low

The testing organisation used for threat-led penetration testing should meet at least the following requirements:

  • Highest suitability and reputability for the task
  • Have technical and organisatory capabilities especially in threat intelligence, penetration testing and red teaming
  • Are certified in a EU member state
  • They provice an audit report in relation to management of risks related to carrying out the testing
  • They are fully covered by relevant insurances including against risks of misconduct and negligence

In the case of using internal testers along with the list above they should be:

  • Approved by competent authority
  • Authority has confirmed the organisation has sufficient resources to perform the testing and conflicts of interest are avoided
  • Threat intelligence provider must be external from the entity

In contracts with the tester management of results and any data processing do not create risks to the organisation.


Article 27: Requirements for testers for the carrying out of TLPT
DORA

Assessments for defining the scope for threat-led penetration testing (TLPT)

Critical
High
Normal
Low

Organization carries out threat-led penetration testing. Each test needs to cover multiple critical or important functions of the related financial entity.

To properly define the proportionate scope for TLPT:

  • Financial entities shall identify relevant ICT systems, processes and technologies supporting critical or important functions
  • Financial entities shall assess which of these need to be covered by the TLPT

The result of this assessment shall determine the precise scope of TLPT and shall be validated by the competent authorities.

Article 26: Advanced testing of ICT tools, systems and processes based on TLPT
DORA

Defining a patch management process

Critical
High
Normal
Low

The organisation should have an adequate patch management procedure defined and implemented. This should include the testing and installation of patches.

There should measures to minimize the risk related to patch management and verification of successful installation of patches.

5.2.5: Vulnerability management
TISAX

Regularly conducting penetration testing with predefined goals and scope

Critical
High
Normal
Low

Penetration testing should have clearly defined goals and scope. The goals may include, e.g., testing continuity plans and capabilities, assessing security controls or identifying security weaknesses. The scope can be defined as follows:

  • - Identify critical parts of the information system that should be prioritized during testing.
  • - Identify individual systems or components that are so vital they must be excluded from testing.

Vital systems or components that could be excluded, e.g., include those essential for maintaining critical organizational services or those unable to withstand the stress of a penetration test.

During the planning phase, it is important to involve relevant stakeholders in advance. This often means informing external system monitoring providers prior to testing, though it may not be necessary to inform users or system management personnel.

Penetration testing should be conducted regularly, at least annually. It should be performed both from outside the organization's network perimeter and from within. Testing from the outside simulates an external attack (black box and white box), while testing from the inside simulates potential threats from compromised clients/servers or malicious insiders (grey box).

The results of penetration tests should always be documented.

No items found.

Regularly conducting penetration testing with predefined goals and scope

Critical
High
Normal
Low

Penetration testing should have clearly defined goals and scope. The goals may include, e.g., testing continuity plans and capabilities, assessing security controls or identifying security weaknesses. The scope can be defined as follows:

  • - Identify critical parts of the information system that should be prioritized during testing.
  • - Identify individual systems or components that are so vital they must be excluded from testing.

Vital systems or components that could be excluded, e.g., include those essential for maintaining critical organizational services or those unable to withstand the stress of a penetration test.

During the planning phase, it is important to involve relevant stakeholders in advance. This often means informing external system monitoring providers prior to testing, though it may not be necessary to inform users or system management personnel.

Penetration testing should be conducted regularly, at least annually. It should be performed both from outside the organization's network perimeter and from within. Testing from the outside simulates an external attack (black box and white box), while testing from the inside simulates potential threats from compromised clients/servers or malicious insiders (grey box).

The results of penetration tests should always be documented.

No items found.

Communicating the results of penetration tests

Critical
High
Normal
Low

The results and reports of penetration tests should be communicated to relevant stakeholders. These tests should be documented with at least a summary, a list of findings, and suggested improvements.

3.4.6: Communicate the results of penetration tests to relevant stakeholders
NSM ICT-SP

Use of of vulnerability scanning and attack tools

Critical
High
Normal
Low

The organization should used vulnerability scanning tools as the main tool for regular vulnerability scanning process.

In addition organization should use attack tools to test those vulnerabilities found with the scanning tool.

3.4.3: Use vulnerability scanning tools and attack tools
NSM ICT-SP

Monitoring the use of the available capacity

Critical
High
Normal
Low

The operation of information systems may depend on certain key resources, such as server capacity,storage space, data processing capacity,monitoring capacity or certain< em>key people.

The organization has defined key resources and methods for monitoring the use of these key resources. A normal level is also determined for the resources, which is used when assessing the risk of jeopardizing availability due to capacity problems.

A1.1: Evaluation of current processing capacity
SOC 2
4.1: Tietojärjestelmien tietoturvallisuus
TiHL: Tietoturva
3.2.5: Verify that the monitoring is working as intended
NSM ICT-SP

Sharing threat intelligence

Critical
High
Normal
Low

Organization should share threat intelligence information actively with other organizations to improve its own threat awareness.

5.7: Threat intelligence
ISO27k1 Full
77: Menettely toimintaympäristön seuraamiseen
Sec overview
THREAT-2: Respond to Threats and Share Threat Information
C2M2: MIL1
Article 45: Information-sharing arrangements on cyber threat information and intelligence
DORA
DE.CM-8: Vulnerability scans are performed.
CyFun

Consideration of threat intelligence findings in the information security risk management process

Critical
High
Normal
Low

Organization must consider the threat intelligence process findings in the information security risk management process. Threat intelligence can detect, for example, the proliferation of certain types of attacks or the development of new technologies, based on which assessments of certain information security risks must be updated, which may lead to the need to reduce risks through treatment plans.

5.7: Threat intelligence
ISO27k1 Full
3.3.4: Obtain and process threat information from relevant sources
NSM ICT-SP

Regular monitoring of the vulnerability management process

Critical
High
Normal
Low

The technical vulnerability management process is regularly monitored and evaluated to ensure its effectiveness and efficiency.

12.6.1: Management of technical vulnerabilities
ISO27 Full
ID.RA-1: Asset vulnerabilities
NIST
PR.IP-12: Vulnerability management plan
NIST
TEK-19: Ohjelmistohaavoittuvuuksien hallinta
Julkri
8.8: Management of technical vulnerabilities
ISO27k1 Full