A typo and a few wording changes.

This is only to improve English language without any changes w.r.t.
content.

Signed-off-by: Kurt Garloff <kurt@garloff.de>

Author: garloff

Standards/scs-0121-w1-Availability-Zones-Standard.md

@@ -12,7 +12,7 @@ supplements:
 
 The standard will not preclude small deployments and edge deployments, that both will not meet the requirement for being divided into multiple Availability Zones.
 Thus multiple Availability Zones are not always present.
-Somtimes there can just be a single Availability Zones.
+Somtimes there can just be a single Availability Zone.
 Because of that, there will be no automated tests to search for AZs.
 
 ## Required Documentation
@@ -26,11 +26,11 @@ For each deployment, that uses more than a single Availability Zone, the CSP has
 4. The redundancy in external connection within each AZ MUST be documented.
 5. The redundancy in core routers within each AZ MUST be documented.
 
-All of these requirements will either not change at all like the fire zones or it is very unlikely for them to change like redundant internet connection.
-Because of this documentation must only be provided in the following cases:
+After the initial setup, these requirements typically do not change at all (like the fire zones) or are very unlikely to change (like redundant internet connection).
+Because of this, documentation needs to only be provided in the following cases:
 
-1. When a new deployment with multiple AZs should be tested for compliance.
-2. When there are physical changes in a deplyoment, which already provided the documentation: the changes needs to be documented and provided as soon as possible.
+1. When a new deployment with multiple AZs should be tested for compliance initially.
+2. When there are physical changes in a deployment, which already provided the documentation: the changes needs to be documented and provided as soon as possible.
 
 ### Alternative Documentation
 
@@ -39,5 +39,5 @@ It is still required to document the existence of fire zones and the correct con
 
 ## Physical Audits
 
-In cases where it is reasonable to mistrust the provided documentation, a physical audit by a natural person - called auditor - send by e.g. the [OSBA](https://osb-alliance.de/) should be performed.
-The CSP of the deployment, which needs such an audit, should grant access to the auditor to the physical infrastructure and should show them all necessary IaaS-Layer configurations, that are needed to verify compliance to this standard.
+When reasons exist to mistrust the provided documentation, a physical audit by a natural person - called auditor - sent by e.g. the [OSBA](https://osb-alliance.de/) should be performed.
+The CSP of the deployment in need of such an audit should grant access for the auditor to the physical infrastructure and should show them all necessary IaaS-Layer configurations that are needed to verify compliance to this standard.