diff --git a/Standards/scs-0216-v1-high-security-setup.md b/Standards/scs-0216-v1-high-security-setup.md
index 36e3bb1b2..2b567e1e7 100644
--- a/Standards/scs-0216-v1-high-security-setup.md
+++ b/Standards/scs-0216-v1-high-security-setup.md
@@ -15,7 +15,7 @@ Nevertheless, a provider (or even a customer) needs to take action in order to a
 hardened, secure cluster due to the myriad of configurations possible. This is especially
 the case since Kubernetes ships with insecure features and configurations out of the box,
 which will need to be mitigated by an administrator with the proper knowledge.
-Hardened, secure Kubernetes clusters are desirable regardless of the possible threat model, 
+Hardened, secure Kubernetes clusters are desirable regardless of the possible threat model,
 since higher security doesn't necessarily mean higher complexity in this case.
 
 ## Motivation
@@ -111,7 +111,7 @@ Multiple policies can be setup to limit and control the capabilities of workload
 especially in order to prevent malicious actors from exploiting obvious faults or even to
 just prevent incorrectly configured workloads from overusing resources.
 
-An easy way to do this would be Resource Limiting on a cluster. This can be done on a per-namespace 
+An easy way to do this would be Resource Limiting on a cluster. This can be done on a per-namespace
 basis and can prevent the overuse of resources or even prevent the creation of too many pods, services or volumes.
 
 It is also possible to change the security context of a pod, which changes different settings of a pod, like