diff --git a/design/20210209.certificates.k8s.io-adoption.md b/design/20210209.certificates.k8s.io-adoption.md
index fd5901b4e..2d526a6a7 100644
--- a/design/20210209.certificates.k8s.io-adoption.md
+++ b/design/20210209.certificates.k8s.io-adoption.md
@@ -54,7 +54,7 @@ the core Kubernetes resource type. This gives cert-manager the ability to
 integrate with components that it otherwise wouldn't have, without changes to the
 third-party project.
 
-Having the "request" resource managed inside the API server has better a
+Having the "request" resource managed inside the API server has a better
 security profile (i.e. `UserInfo` fields are managed by the API server rather
 than a configurable webhook,
 [see](https://github.com/jetstack/cert-manager/pull/3630)).
@@ -66,8 +66,8 @@ to be installed and the webhook ready for consumers/clients of this API to make
 requests.
 
 Support for the `CertificateSigningRequest` resource in cert-manager is a
-stepping stone to migrating to this resource in favour of the
-`CertificateRequest` resource, if the project does indeed want to migrate.
+stepping stone to migrating to this resource instead of the `CertificateRequest`
+resource, if the project does indeed want to migrate.
 
 ### Goals
 
@@ -88,13 +88,13 @@ Bellow are a summary of properties of the `CertificateSigningRequest` which
 cause issues or caveats which need to be addressed when adding support for the
 resource.
 
-### Read all access to `CertificateSigningRequests`
+### Read all access to CertificateSigningRequests
 
 `CertificateSigningRequests` are cluster scoped resources, whereas
 `CertificateRequests` are not. This means that in order for users to have the
 same debugging and usage capabilities of the `CertificateRequest`, users will
 have the ability to list all requests in the cluster, rather than being scoped to
-specific namespaces.
+specific namespaces. This is a regression in security.
 
 A solution to this problem could be given to users by providing examples or
 guides to external tooling (e.g. [Open Policy Agent
@@ -103,19 +103,19 @@ can limit users access to certain `CertificateSigningRequests` based on label
 selectors.
 
 
-### Namespaced issuers referenced by `CertificateSigningRequest`
+### Namespaced issuers referenced by CertificateSigningRequest
 
 `CertificateSigningRequests` are cluster scoped resources, whereas
 `CertificateRequests` are not. cert-manager has the concept of of namespaced
 issuers that may only be referenced by `CertificateRequests` that reside in
 the same namespace. Since `CertificateSigningRequests` can reference any
 namespaced `Issuer`, there must be some mechanism to prevent privilege
-escalation.
+escalation (Alice references an issuer in Bob's namespace).
 
 cert-manager will enforce an
 [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) noun and
 verb whereby the requester must have this role bound to them, in order for the
-`CertificateSigningRequest` referencing a namespaced `Issuer`, be approved by the
+`CertificateSigningRequest` referencing a namespaced `Issuer` be approved by the
 cert-manager controller. See [here](#conditions).
 
 This will be done via a
@@ -160,8 +160,8 @@ signers if and when the migration to `CertificateSigningRequests` occurs.
 ## Proposal
 
 cert-manager will support both `CertificateRequest` and
-`CertificateSigningRequest` types until and if the project completely migrates to
-the `CertificateSigningRequest` resource. The `Certificates` controller will
+`CertificateSigningRequest` types until, and if, the project completely migrates
+to the `CertificateSigningRequest` resource. The `Certificates` controller will
 continue to create `CertificateRequest` resources, unless a flag is changed on
 the cert-manager controller. This default can be switched in future.