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. |
DE.AE-06.1: Information about adverse events shall be promptly delivered to authorised person- nel and systems to enable timely detection, investigation, and response. |
|
DE.AE-06.1 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_ESSENTIAL_E_p159 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_IMPORTANT_E_p105 |
|
|
Relates a concept to a concept that is more general in meaning. |
|
|
A general note, for any purpose. |
The goal of this control is to ensure that information about adverse events is delivered promptly to the right people and systems, so that appropriate action can be taken without delay. This supports faster detection, investigation, and response to potential threats or disruptions. To achieve the goal of this control, consider the following: • Types of Adverse Events Include indicators such as unusual account activity, unauthorised access, system configuration changes, physical security breaches, or malware alerts. • Detection and Alerting Use cybersecuritytools to detect such events and automaticallyalert authorised personnel (e.g. SOC analysts, incident responders). • Integration with Ticketing Systems Alerts should be integrated with the organisation’s ticketing system. Tickets should be: o Automatically generated for predefined alert types. o Manually created when technical staff identify suspicious activity. • Access to Logs and Analysis Authorised staff must have continuous access to log data and analysis results to support investigations. • Maturity and Effectiveness Assessment Evaluate the control’s implementation by checking: o Documentation of procedures for alert generation, review, and escalation.This documentation should be regularly reviewed and updated. o Use of automation for standard alerts, with manual processes as a backup. o Access controls for alerts and logs, with periodic reviews of permissions (Access to alerts and logs should be limited to authorised personnel). o Monitoring and reporting should for example track the number of alerts, response times, and whether procedures are followed. o Training should be provided regularly to staff responsible for handling alerts, ensuring they understand how to interpret and act on them. |
|
A general note, for any purpose. |
The goal of this control is to ensure that information about adverse events is delivered promptly to the right people and systems, so that appropriate action can be taken without delay. This supports faster detection, investigation, and response to potential threats or disruptions. To achieve the goal of this control, consider the following: - Types of Adverse Events Include indicators such as unusual account activity, unauthorised access, system configuration changes, physical security breaches, or malware alerts. - Detection and Alerting Use cybersecuritytools to detect such events and automaticallyalert authorised personnel (e.g. SOC analysts, incident responders). - Integration with Ticketing Systems Alerts should be integrated with the organisation’s ticketing system. Tickets should be: - Automatically generated for predefined alert types. - Manually created when technical staff identify suspicious activity. - Access to Logs and Analysis Authorised staff must have continuous access to log data and analysis results to support investigations. - Maturity and Effectiveness Assessment Evaluate the control’s implementation by checking: - Documentation of procedures for alert generation, review, and escalation.This documentation should be regularly reviewed and updated. - Use of automation for standard alerts, with manual processes as a backup. - Access controls for alerts and logs, with periodic reviews of permissions (Access to alerts and logs should be limited to authorised personnel). - Monitoring and reporting should for example track the number of alerts, response times, and whether procedures are followed. - Training should be provided regularly to staff responsible for handling alerts, ensuring they understand how to interpret and act on them. |
|
A general note, for any purpose. |
<div><p>The goal of this control is to ensure that information about adverse events is delivered promptly to the right people and systems, so that appropriate action can be taken without delay. This supports faster detection, investigation, and response to potential threats or disruptions. To achieve the goal of this control, consider the following:</p><ul><li>Types of Adverse Events Include indicators such as unusual account activity, unauthorised access, system configuration changes, physical security breaches, or malware alerts.</li><li>Detection and Alerting Use cybersecuritytools to detect such events and automaticallyalert authorised personnel (e.g. SOC analysts, incident responders).</li><li>Integration with Ticketing Systems Alerts should be integrated with the organisation’s ticketing system. Tickets should be:<ul><li>Automatically generated for predefined alert types.</li><li>Manually created when technical staff identify suspicious activity.</li></ul></li><li>Access to Logs and Analysis Authorised staff must have continuous access to log data and analysis results to support investigations.</li><li>Maturity and Effectiveness Assessment Evaluate the control’s implementation by checking:<ul><li>Documentation of procedures for alert generation, review, and escalation.This documentation should be regularly reviewed and updated.</li><li>Use of automation for standard alerts, with manual processes as a backup.</li><li>Access controls for alerts and logs, with periodic reviews of permissions (Access to alerts and logs should be limited to authorised personnel).</li><li>Monitoring and reporting should for example track the number of alerts, response times, and whether procedures are followed.</li><li>Training should be provided regularly to staff responsible for handling alerts, ensuring they understand how to interpret and act on them.</li></ul></li></ul></div> |
|
A general note, for any purpose. |
The goal of this control is to ensure that information about adverse events is delivered promptly to the right people and systems, so that appropriate action can be taken without delay. This supports faster detection, investigation, and response to potential threats or disruptions. To achieve the goal of this control, consider the following: - Types of Adverse Events Include indicators such as unusual account activity, unauthorised access, system configuration changes, physical security breaches, or malware alerts. - Detection and Alerting Use cybersecuritytools to detect such events and automaticallyalert authorised personnel (e.g. SOC analysts, incident responders). - Integration with Ticketing Systems Alerts should be integrated with the organisation’s ticketing system. Tickets should be: - Automatically generated for predefined alert types. - Manually created when technical staff identify suspicious activity. - Access to Logs and Analysis Authorised staff must have continuous access to log data and analysis results to support investigations. - Maturity and Effectiveness Assessment Evaluate the control’s implementation by checking: - Documentation of procedures for alert generation, review, and escalation.This documentation should be regularly reviewed and updated. - Use of automation for standard alerts, with manual processes as a backup. - Access controls for alerts and logs, with periodic reviews of permissions (Access to alerts and logs should be limited to authorised personnel). - Monitoring and reporting should for example track the number of alerts, response times, and whether procedures are followed. - Training should be provided regularly to staff responsible for handling alerts, ensuring they understand how to interpret and act on them. |
|
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. |
DE.AE-06.1 |
|
skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties. |
Adverse event notification |
|
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 about adverse events shall be promptly delivered to authorised person- nel and systems to enable timely detection, investigation, and response. |
|
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