diff --git a/rules/S7203/secrets/rule.adoc b/rules/S7203/secrets/rule.adoc
index 38dbd7965f6..dbb94d220d5 100644
--- a/rules/S7203/secrets/rule.adoc
+++ b/rules/S7203/secrets/rule.adoc
@@ -10,11 +10,11 @@ include::../../../shared_content/secrets/impact/private_key_disclosure.adoc[]
 
 include::../../../shared_content/secrets/impact/supply_chain_attack.adoc[]
 
-If a third party gets access to a keystore containingan Android upload key or app signing key, this person could sign and distribute malicious apps under the same identity as the original app.
+If a third party gets access to a keystore containing an Android upload key or app signing key, this person could sign and distribute malicious apps under the same identity as the original app.
 
 == How to fix it
 
-include::../../../shared_content/secrets/fix/store_separatly.adoc[]
+include::../../../shared_content/secrets/fix/store_separately.adoc[]
 
 include::../../../shared_content/secrets/fix/revoke.adoc[]
 
@@ -45,7 +45,7 @@ keytool -genkey \
 
 ==== Compliant solution
 
-Keychain files whould created using a strong password.
+Keychain files should be created using a strong password.
 
 [source,shell,diff-id=1,diff-type=compliant]
 ----
@@ -58,7 +58,7 @@ echo $STRONG_PWD | keytool -genkey \
     -dname "CN=com.example"
 ----
 
-Files containing cryptographic key should not be commitied with the application codebase and should be distributed separatly.
+Files containing cryptographic keys should not be commited with the application codebase and should be distributed separately.
 
 //=== How does this work?
 
diff --git a/shared_content/secrets/fix/store_separately.adoc b/shared_content/secrets/fix/store_separately.adoc
new file mode 100644
index 00000000000..fdbc78925cc
--- /dev/null
+++ b/shared_content/secrets/fix/store_separately.adoc
@@ -0,0 +1,4 @@
+**Store cryptographic keys separately** 
+
+Store private keys separately from the main codebase, even if they are in a password-protected format.
+It will avoid unnecessary exposure and mitigate the risk of private keys being leaked if the password is compromised.
diff --git a/shared_content/secrets/fix/store_separatly.adoc b/shared_content/secrets/fix/store_separatly.adoc
deleted file mode 100644
index 51345f2b516..00000000000
--- a/shared_content/secrets/fix/store_separatly.adoc
+++ /dev/null
@@ -1,4 +0,0 @@
-**Store cryptographic keys separately** 
-
-Store private key separately from the main codebase, even if they are in a password protected format.
-It will avoid unecessary exposure and mitigate the risk of private key being leaked if the password is compromised.
diff --git a/shared_content/secrets/impact/private_key_disclosure.adoc b/shared_content/secrets/impact/private_key_disclosure.adoc
index f3c6be217fd..62c33f5a6c1 100644
--- a/shared_content/secrets/impact/private_key_disclosure.adoc
+++ b/shared_content/secrets/impact/private_key_disclosure.adoc
@@ -10,7 +10,7 @@ higher-level security mechanisms such as:
 
 * User authentication
 * Servers authentication, for example in the X509 trust model
-* E-mail encryption
+* Email encryption
 
 Disclosing a cryptographic private key to an unintended audience can have severe
 security consequences. The exact impact will vary depending on the role of the
@@ -22,6 +22,6 @@ to impersonate that server. This leads to Man-In-The-Middle-Attacks that would
 affect both the confidentiality and integrity of the communications from clients
 to that server.
 
-If the key was used as part of e-mail protocols, attackers might be able to send
-e-mails on behalf of the key owner or decrypt previously encrypted emails. This
-might lead to sensitive information disclosure and reputation loss.
\ No newline at end of file
+If the key was used as part of email protocols, attackers might be able to send
+emails on behalf of the key owner or decrypt previously encrypted emails. This
+might lead to sensitive information disclosure and reputation loss.