diff --git a/doc/user/application_security/policies/index.md b/doc/user/application_security/policies/index.md
index fd5e5ca0b2d706704e4a4ee402a9cfaf41d46e09..0979b1043dd1eebe064ef21dc7df8551299140cb 100644
--- a/doc/user/application_security/policies/index.md
+++ b/doc/user/application_security/policies/index.md
@@ -12,21 +12,25 @@ DETAILS:
 
 > [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/321258) in GitLab 14.4. Feature flag `security_orchestration_policies_configuration` removed.
 
-Policies in GitLab provide security and compliance teams with a way to enforce controls globally in
-their organization. Security teams can ensure:
+Policies provide security and compliance teams with a way to enforce controls globally in
+their organization.
+
+Security teams can ensure:
 
 - Security scanners are enforced in development team pipelines with proper configuration.
 - That all scan jobs execute without any changes or alterations.
 - That proper approvals are provided on merge requests based on results from those findings.
 
-Compliance teams can centrally enforce multiple approvers on all merge requests and ensure various
-settings are enabled on projects in scope of organizational requirements, such as enabling or
-locking merge request and repository settings.
+Compliance teams can:
+
+- Centrally enforce multiple approvers on all merge requests
+- Enforce various settings on projects in scope of organizational requirements, such as enabling or
+  locking merge request and repository settings.
 
-GitLab supports the following security policies:
+The following policy types are available:
 
-- [Scan Execution Policy](scan-execution-policies.md)
-- [Scan Result Policy](scan-result-policies.md)
+- [Scan execution policy](scan-execution-policies.md). Enforce security scans, either as part of the pipeline or on a specified schedule.
+- [Merge request approval policy](scan-result-policies.md). Enforce project-level settings and approval rules based on scan results.
 
 ## Security policy project
 
@@ -93,7 +97,7 @@ Assuming no policies have already been enforced, consider the following examples
   Engineering, and all their projects and subgroups. If the "Secret Detection" policy is enforced
   also at subgroup "Accounts receiving", both policies apply to projects B and C. However, only the
   "SAST" policy applies to project A.
-- If the "SAST policy is enforced at subgroup "Accounts receiving", it applies only to projects B
+- If the "SAST" policy is enforced at subgroup "Accounts receiving", it applies only to projects B
   and C. No policy applies to project A.
 - If the "Secret Detection" is enforced at project K, it applies only to project K. No other
   subgroups or projects have a policy apply to them.
diff --git a/doc/user/application_security/policies/scan-result-policies.md b/doc/user/application_security/policies/scan-result-policies.md
index aea7e57276f9cacc5d33ceaed7dce48f4cbc094f..626d147c9a4e93034b5dbc3541f90eeba95c0749 100644
--- a/doc/user/application_security/policies/scan-result-policies.md
+++ b/doc/user/application_security/policies/scan-result-policies.md
@@ -16,7 +16,7 @@ DETAILS:
 NOTE:
 Scan result policies feature was renamed to merge request approval policies in GitLab 16.9.
 
-You can use merge request approval policies to enforce project level settings and create approval rules based on scan results. For example, one type of scan
+Use merge request approval policies to enforce project-level settings and approval rules based on scan results. For example, one type of scan
 result policy is a security approval policy that allows approval to be required based on the
 findings of one or more security scan jobs. Merge request approval policies are evaluated after a CI scanning job is fully executed and both vulnerability and license type policies are evaluated based on the job artifact reports that are published in the completed pipeline.