@@ -1362,7 +1362,7 @@ There are three different types of assessments used in this document.
**Objective:** Understanding what is collected helps user to undrestand what happens, but also is needed for data minimisation validation.<br/>
**Preparation:**
1. Have the NMS product initialised and available with the default configuration and required credentials.
1. Have the product initialised and available with the default configuration and required credentials.
**Activities:**
@@ -1558,7 +1558,8 @@ There are three different types of assessments used in this document.
#### 6.3.8.0 REQ-HA-0
**Objective:** Expected availability is defined for each relevant system component.<br/>
**Requirement:** Expected availability shall be defined for each relevant system component.<br/>
**Objective:**
**Preparation:**
1. Have the NMS product initialised and available with the default configuration and required credentials.
@@ -1579,7 +1580,8 @@ There are three different types of assessments used in this document.
#### 6.3.8.1 REQ-HA-1
**Objective:** System tolerates loss of resources.<br/>
**Requirement:** System updates and changes shall be included in the availability time definition.<br/>
**Objective:**<br/>
**Preparation:**
1. Have the NMS product initialised and available with the default configuration and required credentials.
@@ -1598,44 +1600,74 @@ There are three different types of assessments used in this document.
1. Structured log output or other documentation that shows made actions and perceived operative response.
#### 6.3.8.2 REQ-HA-2
**Objective:** Disaster recovery plan is available.<br/>
**Objective:** System updates and changes are included in the availability definition.<br/>
**Preparation:** None <br/>
**Activities:**
1. Cross-reference the disaster recovery plan with the distribution description.
1. Cross-reference the disaster recovery plan with the deployment plan and system architecture.
1. Study the availability definition and the presented metrics.
**Verdict:**
1. Pass if recovery expectations are clearly defined
1. and the distribution to the system operation is within reasonable scope in regards of the production size.
1. Pass if system changes, updates and upgrades are not considered to be outside of the availability definition and tracking.
1. Fail otherwise.
**Supporting Evidence:**
1. Written evaluation.
1. Pointers to the documentation.
#### 6.3.8.2 REQ-HA-2
**Requirement:** System shall tolerate loss of resources within the limits of the defined availability.<br/>
**Objective:** The customer understands how the sytem behaves undre different conditions and can make a disaster recovery plan for the operation.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
**Activities:**
1. Study the availability definition from the documentation.
2. Delete or make unavailable: service, compute node, rack, or datacenter based on the what the system design tolerates.
3. Wait for stability.
4. Return the resrouce taken away in previous step.
5. Wait for stability.
**Verdict:**
1. Pass if recovery expectations are clearly defined,
2. and the system returns to stability after removal of the largest resource in the toleration description,
3. and the deleted or removed resources returns operation after they are reintroduced to the system,
4. and the defined high availability is hold.
5. Fail otherwise.
**Supporting Evidence:**
1. Pointers to the documentation.
2. Description of the test procedure and relevant bits of log showing the phases.
#### 6.3.8.3 REQ-HA-3
**Objective:** System updates and changes are included in the availability definition.<br/>
**Requirement:** Recovery capabilities shall be made available in the technical documentation and are sufficient to implement the expected availability.<br/>
**Objective:** The customer understands how the sytem behaves undre different conditions and can make a disaster recovery plan for the operation.<br/>
**Preparation:** None <br/>
**Activities:**
1. Study the availability definition and the presented metrics.
1. Cross-reference the recovery capabilities with the distribution description.
2. Cross-reference the recovery capabilities with the deployment plan and system architecture.
**Verdict:**
1. Pass if system changes, updates and upgrades are not considered to be outside of the availability definition and tracking.
1. Pass if recovery expectations are clearly defined
1. and the distribution of the system operation is within reasonable scope in regards of the production size.
1. Fail otherwise.
**Supporting Evidence:**
1. Pointers to the documentation.
# Annex A (informative): Mapping with essential requirements of the CRA
> Table mapping technical cybersecurity requirements from Section 5 of the present document to essential cybersecurity requirements in Annex I of the CRA. The purpose of this is to help identify missing technical cybersecurity requirements.
