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-06.2: Physical access controls shall include specific procedures for emergency situations, ensuring continued protection of critical and non-critical assets during such events. |
|
PR.AA-06.2 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_ESSENTIAL_E_p101 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_IMPORTANT_E_p73 |
|
|
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 physical access controls remain effective and adaptable during emer- gency situations. This includes maintaining security over critical and non-critical assets while enabling safe, authorised, and traceable access for emergency response, recovery, or containment actions — especially in environments where physical and operational safety are tightly linked, such as Operational Technology (OT) and Internet of Things (IoT) systems. To achieve this goal, the organisation should: - Define Emergency Scenarios Emergency procedures should cover a range of events, including: - Environmental and safety incidents (e.g. fire, flood, medical emergencies, evacuations) - Infrastructure failures (e.g. power outages, system malfunctions) - Security incidents (e.g. intrusions, access control failures) - Cybersecurity events (e.g. ransomware, data breaches, insider threats) - Maintain EmergencyAccess Procedures Emergency access should be: - Logged: Record who accessed what, when, and why. - Monitored: Use surveillance or access control systems to track activity. - Reviewed: Conduct post-event reviews to verify appropriate use and detect misuse. - Support Emergency Readiness with Physical Controls - Up-to-date lists of authorised individuals with emergency access rights should be maintained. - Identity credentials (e.g. access badges) should be used and security zones defined. - Escort requirements should be applied for visitors or temporary personnel. - Physical barriers should be implemented such as fences, locks, turnstiles, and staffed checkpoints. - Surveillance systems should be used to monitor entry and exit points. - ApplyAdditional Safeguards - Badge systems with differentiated access levels for various zones should be considered. - Physical access to servers and network components should be restricted to authorised personnel only. - All access to critical infrastructure should be logged and reviewed regularly. - Maintain and review —Visitor access records should be maintained and reviewed. Corrective action should be taken when necessary. - Ensure OT-Specific Feasibility In OTenvironments, physical access procedures should be adapted to avoid disrupting safetyoroperational continuity. Emergency access should be designed to support both rapid response and asset protection. - Align with ENISA Guidance These practices alignwith ENISA’s NIS2Technical Implementation Guidance,which highlights the importance of physical and logical access controls in maintaining resilience during emergencies. |
|
A general note, for any purpose. |
The goal of this control is to ensure that physical access controls remain effective and adaptable during emer- gency situations. This includes maintaining security over critical and non-critical assets while enabling safe, authorised, and traceable access for emergency response, recovery, or containment actions — especially in environments where physical and operational safety are tightly linked, such as Operational Technology (OT) and Internet of Things (IoT) systems. To achieve this goal, the organisation should: • Define Emergency Scenarios Emergency procedures should cover a range of events, including: o Environmental and safety incidents (e.g. fire, flood, medical emergencies, evacuations) o Infrastructure failures (e.g. power outages, system malfunctions) o Security incidents (e.g. intrusions, access control failures) o Cybersecurity events (e.g. ransomware, data breaches, insider threats) • Maintain EmergencyAccess Procedures Emergency access should be: o Logged: Record who accessed what, when, and why. o Monitored: Use surveillance or access control systems to track activity. o Reviewed: Conduct post-event reviews to verify appropriate use and detect misuse. • Support Emergency Readiness with Physical Controls o Up-to-date lists of authorised individuals with emergency access rights should be maintained. o Identity credentials (e.g. access badges) should be used and security zones defined. o Escort requirements should be applied for visitors or temporary personnel. o Physical barriers should be implemented such as fences, locks, turnstiles, and staffed checkpoints. o Surveillance systems should be used to monitor entry and exit points. • ApplyAdditional Safeguards o Badge systems with differentiated access levels for various zones should be considered. o Physical access to servers and network components should be restricted to authorised personnel only. o All access to critical infrastructure should be logged and reviewed regularly. o Maintain and review —Visitor access records should be maintained and reviewed. Corrective action should be taken when necessary. • Ensure OT-Specific Feasibility In OTenvironments, physical access procedures should be adapted to avoid disrupting safetyoroperational continuity. Emergency access should be designed to support both rapid response and asset protection. • Align with ENISA Guidance These practices alignwith ENISA’s NIS2Technical Implementation Guidance,which highlights the importance of physical and logical access controls in maintaining resilience during emergencies. |
|
A general note, for any purpose. |
<div><p>The goal of this control is to ensure that physical access controls remain effective and adaptable during emer- gency situations. This includes maintaining security over critical and non-critical assets while enabling safe, authorised, and traceable access for emergency response, recovery, or containment actions — especially in environments where physical and operational safety are tightly linked, such as Operational Technology (OT) and Internet of Things (IoT) systems. To achieve this goal, the organisation should:</p><ul><li>Define Emergency Scenarios Emergency procedures should cover a range of events, including:<ul><li>Environmental and safety incidents (e.g. fire, flood, medical emergencies, evacuations)</li><li>Infrastructure failures (e.g. power outages, system malfunctions)</li><li>Security incidents (e.g. intrusions, access control failures)</li><li>Cybersecurity events (e.g. ransomware, data breaches, insider threats)</li></ul></li><li>Maintain EmergencyAccess Procedures Emergency access should be:<ul><li>Logged: Record who accessed what, when, and why.</li><li>Monitored: Use surveillance or access control systems to track activity.</li><li>Reviewed: Conduct post-event reviews to verify appropriate use and detect misuse.</li></ul></li><li>Support Emergency Readiness with Physical Controls<ul><li>Up-to-date lists of authorised individuals with emergency access rights should be maintained.</li><li>Identity credentials (e.g. access badges) should be used and security zones defined.</li><li>Escort requirements should be applied for visitors or temporary personnel.</li><li>Physical barriers should be implemented such as fences, locks, turnstiles, and staffed checkpoints.</li><li>Surveillance systems should be used to monitor entry and exit points.</li></ul></li><li>ApplyAdditional Safeguards<ul><li>Badge systems with differentiated access levels for various zones should be considered.</li><li>Physical access to servers and network components should be restricted to authorised personnel only.</li><li>All access to critical infrastructure should be logged and reviewed regularly.</li><li>Maintain and review —Visitor access records should be maintained and reviewed. Corrective action should be taken when necessary.</li></ul></li><li>Ensure OT-Specific Feasibility In OTenvironments, physical access procedures should be adapted to avoid disrupting safetyoroperational continuity. Emergency access should be designed to support both rapid response and asset protection.</li><li>Align with ENISA Guidance These practices alignwith ENISA’s NIS2Technical Implementation Guidance,which highlights the importance of physical and logical access controls in maintaining resilience during emergencies.</li></ul></div> |
|
A general note, for any purpose. |
The goal of this control is to ensure that physical access controls remain effective and adaptable during emer- gency situations. This includes maintaining security over critical and non-critical assets while enabling safe, authorised, and traceable access for emergency response, recovery, or containment actions — especially in environments where physical and operational safety are tightly linked, such as Operational Technology (OT) and Internet of Things (IoT) systems. To achieve this goal, the organisation should: - Define Emergency Scenarios Emergency procedures should cover a range of events, including: - Environmental and safety incidents (e.g. fire, flood, medical emergencies, evacuations) - Infrastructure failures (e.g. power outages, system malfunctions) - Security incidents (e.g. intrusions, access control failures) - Cybersecurity events (e.g. ransomware, data breaches, insider threats) - Maintain EmergencyAccess Procedures Emergency access should be: - Logged: Record who accessed what, when, and why. - Monitored: Use surveillance or access control systems to track activity. - Reviewed: Conduct post-event reviews to verify appropriate use and detect misuse. - Support Emergency Readiness with Physical Controls - Up-to-date lists of authorised individuals with emergency access rights should be maintained. - Identity credentials (e.g. access badges) should be used and security zones defined. - Escort requirements should be applied for visitors or temporary personnel. - Physical barriers should be implemented such as fences, locks, turnstiles, and staffed checkpoints. - Surveillance systems should be used to monitor entry and exit points. - ApplyAdditional Safeguards - Badge systems with differentiated access levels for various zones should be considered. - Physical access to servers and network components should be restricted to authorised personnel only. - All access to critical infrastructure should be logged and reviewed regularly. - Maintain and review —Visitor access records should be maintained and reviewed. Corrective action should be taken when necessary. - Ensure OT-Specific Feasibility In OTenvironments, physical access procedures should be adapted to avoid disrupting safetyoroperational continuity. Emergency access should be designed to support both rapid response and asset protection. - Align with ENISA Guidance These practices alignwith ENISA’s NIS2Technical Implementation Guidance,which highlights the importance of physical and logical access controls in maintaining resilience during emergencies. |
|
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-06.2 |
|
skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties. |
Emergency physical access procedures |
|
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. |
Physical access controls shall include specific procedures for emergency situations, ensuring continued protection of critical and non-critical assets during such events. |
|
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