1. Relevant metrics described in the technical documentation.
### 6.3.x High availability tests
#### 6.3.x.0 REQ-HA-0
**Objective**: Expected availability is defined for each relevant system component.<br/>
**Preparation**:
1. Have the NMS product initialized and available with the default configuration and required credentials.
**Activities**:
1. Study the metrics for availability information
**Verdict**:
1. Pass all relevant components availability is defined and tracked
1. Fail otherwise.
**Supporting Evidence**:
1. Relevant metrics described in the technical documentation.
1. Screen shots of metrics being visualised in the dashboards.
#### 6.3.x.1 REQ-HA-1
**Objective**: System tolerates loss of resources.<br/>
**Preparation**:
1. Have the NMS product initialized and available with the default configuration and required credentials.
**Activities**:
1. Kill a random process, processing node or simulate a loss of a datacenter.
1. Repeat first step enough of times with varying scopes to demnonstrate comfortance.
**Verdict**:
1. Pass if loss of a resource matching the availability and distribution description doesn't exceed the availabity definition.
1. Fail otherwise.
**Supporting Evidence**:
1. Structured log output or other documentation that shows made actions and perceived operative response.
#### 6.3.x.2 REQ-HA-2
**Objective**: Disaster recovery plan is available.<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.
**Verdict**:
1. Pass if recovery expectations are clearly defined
1. and the distrubtion to the system operation is within reasonable scope in regards of the production size.
1. Fail otherwise.
**Supporting Evidence**:
1. Written evaluation.
#### 6.3.x.3 REQ-HA-3
**Objective**: System updates and changes are included in the availability definition.<br/>
**Preparation**: None <br/>
**Activities**:
1. Study the availability definition and the presented metrics.
**Verdict**:
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. Pointers to the documentation.
# Annex A (informative): Mapping with essential requirements of the CRA
> Table mapping technical security 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 security requirements.
