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. |
PR.AA-05.5: Where technically, operationally, and economically feasible — without compromising system integrity, safety, or compliance — automated mechanisms shall be imple- mented to manage user accounts on critical ICT and OT systems. Feasibility shall be determined based on system capabilities, integration potential, risk assessment, and business impact. |
|
PR.AA-05.5 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_IMPORTANT_E_p69 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_ESSENTIAL_E_p95 |
|
|
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 user accounts on critical ICT and OT systems are managed securely, efficiently, and consistently through automated mechanisms — where technically, operationally, and economi- cally feasible — without compromising system integrity, safety, or compliance. To achieve this goal, the organisation should: - Assess Feasibility of Automation Feasibilityshould be based on system capabilities, integration potential, risk assessment, and business impact. - ForICTsystems, feasibilitydepends on the availabilityofautomation tools,APIs, orintegration options, and the absence of major technical or financial barriers. - For OTsystems, feasibilitydepends on system age,vendor limitations, safetyrequirements, and the risk of disrupting critical operations. - General feasibility should consider technical capability, operational safety, cost-effectiveness, and compli- ance with security and regulatory standards. - Automate Account Lifecycle Management Automated mechanisms should manage account creation, modification, and deletion based on predefined rules. This ensures that only authorised users have access and that accounts are promptly removed when no longer needed. - Disable Inactive or Unauthorised Accounts Accounts should be automatically disabled when users leave the organisation or no longer require access. This reduces the risk of unauthorised access to critical systems. - Monitor and Report Account Activity Automated tools should continuously monitor account usage and generate reports to detect unusual or unauthorised activity. Alerts should be triggered for suspicious behaviour. - Send Notifications for Key Events Automated notifications should inform administrators of important events such as account creation, modi- fication, or deletion, enabling timely oversight. - Maintain Audit Trails for Compliance All account-related activities should be logged automaticallyto support compliancewith internal policies and external regulations. - Ensure OT-Specific Feasibility In OT environments, automation should be implemented only where it does not compromise safety or operational continuity. Where direct automation is not feasible, account management should be handled through secure interface layers or jump servers. - Align with ENISA Guidance These practices are supported by ENISA’s NIS2 Technical Implementation Guidance and its work on secure access management in critical infrastructure environments. |
|
A general note, for any purpose. |
<div><p>The goal of this control is to ensure that user accounts on critical ICT and OT systems are managed securely, efficiently, and consistently through automated mechanisms — where technically, operationally, and economi- cally feasible — without compromising system integrity, safety, or compliance. To achieve this goal, the organisation should:</p><ul><li>Assess Feasibility of Automation Feasibilityshould be based on system capabilities, integration potential, risk assessment, and business impact.<ul><li>ForICTsystems, feasibilitydepends on the availabilityofautomation tools,APIs, orintegration options, and the absence of major technical or financial barriers.</li><li>For OTsystems, feasibilitydepends on system age,vendor limitations, safetyrequirements, and the risk of disrupting critical operations.</li><li>General feasibility should consider technical capability, operational safety, cost-effectiveness, and compli- ance with security and regulatory standards.</li></ul></li><li>Automate Account Lifecycle Management Automated mechanisms should manage account creation, modification, and deletion based on predefined rules. This ensures that only authorised users have access and that accounts are promptly removed when no longer needed.</li><li>Disable Inactive or Unauthorised Accounts Accounts should be automatically disabled when users leave the organisation or no longer require access. This reduces the risk of unauthorised access to critical systems.</li><li>Monitor and Report Account Activity Automated tools should continuously monitor account usage and generate reports to detect unusual or unauthorised activity. Alerts should be triggered for suspicious behaviour.</li><li>Send Notifications for Key Events Automated notifications should inform administrators of important events such as account creation, modi- fication, or deletion, enabling timely oversight.</li><li>Maintain Audit Trails for Compliance All account-related activities should be logged automaticallyto support compliancewith internal policies and external regulations.</li><li>Ensure OT-Specific Feasibility In OT environments, automation should be implemented only where it does not compromise safety or operational continuity. Where direct automation is not feasible, account management should be handled through secure interface layers or jump servers.</li><li>Align with ENISA Guidance These practices are supported by ENISA’s NIS2 Technical Implementation Guidance and its work on secure access management in critical infrastructure environments.</li></ul></div> |
|
A general note, for any purpose. |
The goal of this control is to ensure that user accounts on critical ICT and OT systems are managed securely, efficiently, and consistently through automated mechanisms — where technically, operationally, and economi- cally feasible — without compromising system integrity, safety, or compliance. To achieve this goal, the organisation should: • Assess Feasibility of Automation Feasibilityshould be based on system capabilities, integration potential, risk assessment, and business impact. o ForICTsystems, feasibilitydepends on the availabilityofautomation tools,APIs, orintegration options, and the absence of major technical or financial barriers. o For OTsystems, feasibilitydepends on system age,vendor limitations, safetyrequirements, and the risk of disrupting critical operations. o General feasibility should consider technical capability, operational safety, cost-effectiveness, and compli- ance with security and regulatory standards. • Automate Account Lifecycle Management Automated mechanisms should manage account creation, modification, and deletion based on predefined rules. This ensures that only authorised users have access and that accounts are promptly removed when no longer needed. • Disable Inactive or Unauthorised Accounts Accounts should be automatically disabled when users leave the organisation or no longer require access. This reduces the risk of unauthorised access to critical systems. • Monitor and Report Account Activity Automated tools should continuously monitor account usage and generate reports to detect unusual or unauthorised activity. Alerts should be triggered for suspicious behaviour. • Send Notifications for Key Events Automated notifications should inform administrators of important events such as account creation, modi- fication, or deletion, enabling timely oversight. • Maintain Audit Trails for Compliance All account-related activities should be logged automaticallyto support compliancewith internal policies and external regulations. • Ensure OT-Specific Feasibility In OT environments, automation should be implemented only where it does not compromise safety or operational continuity. Where direct automation is not feasible, account management should be handled through secure interface layers or jump servers. • Align with ENISA Guidance These practices are supported by ENISA’s NIS2 Technical Implementation Guidance and its work on secure access management in critical infrastructure environments. |
|
A general note, for any purpose. |
The goal of this control is to ensure that user accounts on critical ICT and OT systems are managed securely, efficiently, and consistently through automated mechanisms — where technically, operationally, and economi- cally feasible — without compromising system integrity, safety, or compliance. To achieve this goal, the organisation should: - Assess Feasibility of Automation Feasibilityshould be based on system capabilities, integration potential, risk assessment, and business impact. - ForICTsystems, feasibilitydepends on the availabilityofautomation tools,APIs, orintegration options, and the absence of major technical or financial barriers. - For OTsystems, feasibilitydepends on system age,vendor limitations, safetyrequirements, and the risk of disrupting critical operations. - General feasibility should consider technical capability, operational safety, cost-effectiveness, and compli- ance with security and regulatory standards. - Automate Account Lifecycle Management Automated mechanisms should manage account creation, modification, and deletion based on predefined rules. This ensures that only authorised users have access and that accounts are promptly removed when no longer needed. - Disable Inactive or Unauthorised Accounts Accounts should be automatically disabled when users leave the organisation or no longer require access. This reduces the risk of unauthorised access to critical systems. - Monitor and Report Account Activity Automated tools should continuously monitor account usage and generate reports to detect unusual or unauthorised activity. Alerts should be triggered for suspicious behaviour. - Send Notifications for Key Events Automated notifications should inform administrators of important events such as account creation, modi- fication, or deletion, enabling timely oversight. - Maintain Audit Trails for Compliance All account-related activities should be logged automaticallyto support compliancewith internal policies and external regulations. - Ensure OT-Specific Feasibility In OT environments, automation should be implemented only where it does not compromise safety or operational continuity. Where direct automation is not feasible, account management should be handled through secure interface layers or jump servers. - Align with ENISA Guidance These practices are supported by ENISA’s NIS2 Technical Implementation Guidance and its work on secure access management in critical infrastructure environments. |
|
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. |
PR.AA-05.5 |
|
skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties. |
Automated user account management |
|
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. |
Where technically, operationally, and economically feasible — without compromising system integrity, safety, or compliance — automated mechanisms shall be imple- mented to manage user accounts on critical ICT and OT systems. Feasibility shall be determined based on system capabilities, integration potential, risk assessment, and business impact. |
|
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