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.PS-06.2: Changes and exceptions shall be tested and validated before being implemented into operational systems. |
|
PR.PS-06.2 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_IMPORTANT_E_p89 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_ESSENTIAL_E_p128 |
|
|
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 reduce the risk of disruptions or vulnerabilities by ensuring that all changes and exceptions are properly tested and validated before being applied to operational systems. To achieve this goal: - All proposed changes and exceptions should follow a formal process that includes documentation, review, testing, and approval. - The potential risks of applying, or not applying, a change should be assessed and recorded. - Exceptions, defined as approved deviations from standard policies or procedures, should be evaluated with a clear understanding of the risks and a defined plan to reduce or manage them. - Accepted risks should be periodically reviewed to confirm that the original decision to accept them remains valid, especially if conditions change or if the acceptance was based on future actions or milestones. - These practices should be adapted to the operational environment to avoid unplanned downtime or safety issues, especially in OT systems. |
|
A general note, for any purpose. |
The goal of this control is to reduce the risk of disruptions or vulnerabilities by ensuring that all changes and exceptions are properly tested and validated before being applied to operational systems. To achieve this goal: - All proposed changes and exceptions should follow a formal process that includes documentation, review, testing, and approval. - The potential risks of applying, or not applying, a change should be assessed and recorded. - Exceptions, defined as approved deviations from standard policies or procedures, should be evaluated with a clear understanding of the risks and a defined plan to reduce or manage them. - Accepted risks should be periodically reviewed to confirm that the original decision to accept them remains valid, especially if conditions change or if the acceptance was based on future actions or milestones. - These practices should be adapted to the operational environment to avoid unplanned downtime or safety issues, especially in OT systems. |
|
A general note, for any purpose. |
<div><p>The goal of this control is to reduce the risk of disruptions or vulnerabilities by ensuring that all changes and exceptions are properly tested and validated before being applied to operational systems. To achieve this goal:</p><ul><li>All proposed changes and exceptions should follow a formal process that includes documentation, review, testing, and approval.</li><li>The potential risks of applying, or not applying, a change should be assessed and recorded.</li><li>Exceptions, defined as approved deviations from standard policies or procedures, should be evaluated with a clear understanding of the risks and a defined plan to reduce or manage them.</li><li>Accepted risks should be periodically reviewed to confirm that the original decision to accept them remains valid, especially if conditions change or if the acceptance was based on future actions or milestones.</li><li>These practices should be adapted to the operational environment to avoid unplanned downtime or safety issues, especially in OT systems.</li></ul></div> |
|
A general note, for any purpose. |
The goal of this control is to reduce the risk of disruptions or vulnerabilities by ensuring that all changes and exceptions are properly tested and validated before being applied to operational systems. To achieve this goal: • All proposed changes and exceptions should follow a formal process that includes documentation, review, testing, and approval. • The potential risks of applying, or not applying, a change should be assessed and recorded. • Exceptions, defined as approved deviations from standard policies or procedures, should be evaluated with a clear understanding of the risks and a defined plan to reduce or manage them. • Accepted risks should be periodically reviewed to confirm that the original decision to accept them remains valid, especially if conditions change or if the acceptance was based on future actions or milestones. • These practices should be adapted to the operational environment to avoid unplanned downtime or safety issues, especially in OT systems. |
|
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.PS-06.2 |
|
skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties. |
Change testing and validation |
|
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. |
Changes and exceptions shall be tested and validated before being implemented into operational systems. |
|
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