Direct links from the subject.
| Property | Value |
|---|---|
|
The subject is an instance of a class. |
|
|
The subject is an instance of a class. |
An idea or notion; a unit of thought. |
|
A human-readable name for the subject. |
RS.MA-03.1: Information/cybersecurity incidents shall be categorised, prioritised and escalated as determined in the incident response plan. |
|
RS.MA-03.1 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_ESSENTIAL_E_p166 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_IMPORTANT_E_p111 |
|
|
Relates a concept to a concept that is more general in meaning. |
|
|
A general note, for any purpose. |
This control is an evolution ofRS.MA-02.1 and is to ensure that once an incident isvalidated, it is systematically classified and managed based on its nature, urgency, and potential impact, so that the organisation can respond efficiently, consistently, and appropriately. Therefore the following should be considered: • Incidents should be reviewed and classified based on theirtype (e.g. data breach, ransomware, DDoS, account compromise) and the validated magnitude of their impact. • The estimation and validation of an incident’s magnitude — further developed in RS.AN-08.1 (Essential), should inform how incidents are categorised and prioritised. • Indicators such as scope, severity, and time sensitivity should guide prioritisation decisions. • Software Bills of Materials (SBOM) can support impact assessment by identifying affected components and dependencies. • Criteria for categorisation, prioritisation, and escalation should be documented in the incident response plan and applied consistently. • Incident response strategies should balance the need for rapid recovery with the potential benefits of observing attacker behaviour or conducting deeper investigation. • Escalation procedures should be coordinated with designated internal and external stakeholders to ensure timely and appropriate response. |
|
A general note, for any purpose. |
This control is an evolution ofRS.MA-02.1 and is to ensure that once an incident isvalidated, it is systematically classified and managed based on its nature, urgency, and potential impact, so that the organisation can respond efficiently, consistently, and appropriately. Therefore the following should be considered: - Incidents should be reviewed and classified based on theirtype (e.g. data breach, ransomware, DDoS, account compromise) and the validated magnitude of their impact. - The estimation and validation of an incident’s magnitude — further developed in RS.AN-08.1 (Essential), should inform how incidents are categorised and prioritised. - Indicators such as scope, severity, and time sensitivity should guide prioritisation decisions. - Software Bills of Materials (SBOM) can support impact assessment by identifying affected components and dependencies. - Criteria for categorisation, prioritisation, and escalation should be documented in the incident response plan and applied consistently. - Incident response strategies should balance the need for rapid recovery with the potential benefits of observing attacker behaviour or conducting deeper investigation. - Escalation procedures should be coordinated with designated internal and external stakeholders to ensure timely and appropriate response. |
|
A general note, for any purpose. |
This control is an evolution ofRS.MA-02.1 and is to ensure that once an incident isvalidated, it is systematically classified and managed based on its nature, urgency, and potential impact, so that the organisation can respond efficiently, consistently, and appropriately. Therefore the following should be considered: - Incidents should be reviewed and classified based on theirtype (e.g. data breach, ransomware, DDoS, account compromise) and the validated magnitude of their impact. - The estimation and validation of an incident’s magnitude — further developed in RS.AN-08.1 (Essential), should inform how incidents are categorised and prioritised. - Indicators such as scope, severity, and time sensitivity should guide prioritisation decisions. - Software Bills of Materials (SBOM) can support impact assessment by identifying affected components and dependencies. - Criteria for categorisation, prioritisation, and escalation should be documented in the incident response plan and applied consistently. - Incident response strategies should balance the need for rapid recovery with the potential benefits of observing attacker behaviour or conducting deeper investigation. - Escalation procedures should be coordinated with designated internal and external stakeholders to ensure timely and appropriate response. |
|
A general note, for any purpose. |
<div><p>This control is an evolution ofRS.MA-02.1 and is to ensure that once an incident isvalidated, it is systematically classified and managed based on its nature, urgency, and potential impact, so that the organisation can respond efficiently, consistently, and appropriately. Therefore the following should be considered:</p><ul><li>Incidents should be reviewed and classified based on theirtype (e.g. data breach, ransomware, DDoS, account compromise) and the validated magnitude of their impact.</li><li>The estimation and validation of an incident’s magnitude — further developed in RS.AN-08.1 (Essential), should inform how incidents are categorised and prioritised.</li><li>Indicators such as scope, severity, and time sensitivity should guide prioritisation decisions.</li><li>Software Bills of Materials (SBOM) can support impact assessment by identifying affected components and dependencies.</li><li>Criteria for categorisation, prioritisation, and escalation should be documented in the incident response plan and applied consistently.</li><li>Incident response strategies should balance the need for rapid recovery with the potential benefits of observing attacker behaviour or conducting deeper investigation.</li><li>Escalation procedures should be coordinated with designated internal and external stakeholders to ensure timely and appropriate response.</li></ul></div> |
|
A notation, also known as classification code, is a string of characters such as "T58.5" or "303.4833" used to uniquely identify a concept within the scope of a given concept scheme. |
RS.MA-03.1 |
|
skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties. |
Incident categorisation and escalation |
|
A resource has no more than one value of skos:prefLabel per language tag, and no more than one value of skos:prefLabel without language tag. |
Information/cybersecurity incidents shall be categorised, prioritised and escalated as determined in the incident response plan. |
|
Relates a resource (for example a concept) to a concept scheme in which it is included. |
|
|
Relates a resource (for example a concept) to a concept scheme in which it is included. |
http://cyfun.data.gift/data/CyFun2025_delta_BASIC_to_IMPORTANT |
|
Relates a resource (for example a concept) to a concept scheme in which it is included. |
|
|
Relates a resource (for example a concept) to a concept scheme in which it is included. |
|
|
The number of triples associated with the subject. |
19 |
|
Specifies the dataset the subject is part of. |
Resultaten 1 - 21 of 21
Inverse links to the subject.
| Property | Subject |
|---|---|
|
Relates a concept to a concept that is more specific in meaning. |
Resultaten 1 - 1 of 1