diff --git a/docs/release/role-handbooks/ci-signal/README.md b/docs/release/role-handbooks/ci-signal/README.md
index 11484cc54796..3808d23ce724 100644
--- a/docs/release/role-handbooks/ci-signal/README.md
+++ b/docs/release/role-handbooks/ci-signal/README.md
@@ -68,8 +68,10 @@ The goal of this task is to keep our tests running in CI stable.
     1. Create an issue using an appropriate template (failing-test) in the Cluster API repository to surface the CI failure.
     2. Identify if the issue is a known issue, new issue or a regression.
     3. Mark the issue as `release-blocking` if applicable.
-6. Triage periodic GitHub actions failures, with special attention to image scan results;
-   Eventually open issues as described above.
+6. Triage periodic GitHub actions failures and image scan results.
+    * Ensure that the release branch is stable and all tests are passing on [testgrid](https://testgrid.k8s.io/sig-cluster-lifecycle-cluster-api).
+    * Verify the [Weekly security scan](https://github.com/kubernetes-sigs/cluster-api/actions/workflows/weekly-security-scan.yaml) results are clean.
+    * Eventually open issues as described above.
 7. Run periodic deep-dive sessions with the CI team to investigate failing and flaking tests. Example session recording: https://www.youtube.com/watch?v=YApWftmiDTg
 
   **Note**: Maintaining the health of the project is a community effort.  CI team should use all of the tools available to them to attempt to keep the CI signal clean, however the [#cluster-api](https://kubernetes.slack.com/archives/C8TSNPY4T) Slack channel should be used to increase visibility of release blocking interruptions to the CI signal and seek help from community.  This should be *additive* to the steps described above. When in doubt, err on the side of overcommunication to promote awareness and drive disruptions to resolution.  
diff --git a/docs/release/role-handbooks/release-lead/README.md b/docs/release/role-handbooks/release-lead/README.md
index 4d3a2586bfcc..f7b31ff284f7 100644
--- a/docs/release/role-handbooks/release-lead/README.md
+++ b/docs/release/role-handbooks/release-lead/README.md
@@ -172,7 +172,9 @@ to a newer Go minor version according to our [backport policy](./../../../../CON
 ### [Repeatedly] Cut a release
 
 1. Ensure CI is stable before cutting the release (e.g. by checking with the CI manager)
-   Note: special attention should be given to image scan results, so we can avoid cutting a release with CVE or document known CVEs in release notes.
+   * Ensure there are no [open PRs or issues that are blocking the release](https://github.com/kubernetes-sigs/cluster-api/issues?q=label%3Akind%2Frelease-blocking%20state%3Aopen).
+   * Ensure that the release branch is stable and all tests are passing on [testgrid](https://testgrid.k8s.io/sig-cluster-lifecycle-cluster-api).
+   * Verify the [Weekly security scan](https://github.com/kubernetes-sigs/cluster-api/actions/workflows/weekly-security-scan.yaml) results are clean.
 2. Ask the [Communications/Docs/Release Notes Manager](../communications/README.md) to [create a PR with the release notes](../communications/README.md#create-pr-for-release-notes) for the new desired tag and review the PR. Once the PR merges, it will trigger a [GitHub Action](https://github.com/kubernetes-sigs/cluster-api/actions/workflows/release.yaml) to create a release branch, push release tags, and create a draft release. This will also trigger a [ProwJob](https://prow.k8s.io/?repo=kubernetes-sigs%2Fcluster-api&job=post-cluster-api-push-images) to publish images to the staging repository.
 3. Promote images from the staging repository to the production registry (`registry.k8s.io/cluster-api`):
     1. Wait until images for the tag have been built and pushed to the [staging repository](https://console.cloud.google.com/gcr/images/k8s-staging-cluster-api) by the [post push images job](https://prow.k8s.io/?repo=kubernetes-sigs%2Fcluster-api&job=post-cluster-api-push-images).