diff --git a/docs/book/src/clusterctl/commands/init.md b/docs/book/src/clusterctl/commands/init.md
index fc4746f4c54b..31a851dbc88e 100644
--- a/docs/book/src/clusterctl/commands/init.md
+++ b/docs/book/src/clusterctl/commands/init.md
@@ -19,6 +19,10 @@ You can use the `clusterctl config repositories` command to get a list of suppor
 If the provider of your choice is missing, you can customize the list of supported providers by using the
 [clusterctl configuration](../configuration.md) file.
 
+Important! The Cluster API project supports ecosystem growth and extensibility. The `clusterctl` CLI carries a list of
+predefined providers sponsored by SIG Cluster Lifecycle, and out-of-organization third party open-source repositories.
+Each repository is the responsibility of the respective maintainers, including their quality standards and support.
+
 </aside>
 
 #### Automatically installed providers
diff --git a/docs/book/src/clusterctl/provider-contract.md b/docs/book/src/clusterctl/provider-contract.md
index 55b2c944f2a2..da52a09dfc46 100644
--- a/docs/book/src/clusterctl/provider-contract.md
+++ b/docs/book/src/clusterctl/provider-contract.md
@@ -25,7 +25,7 @@ Optionally, the provider repository can include the following files:
 <h1> Pre-defined list of providers </h1>
 
 The `clusterctl` command ships with a pre-defined list of provider repositories that allows a simpler "out-of-the-box" user experience.
-As a provider implementer, if you are interested in being added to this list, please create an issue to the [Cluster API repository](https://sigs.k8s.io/cluster-api).
+As a provider implementer, if you are interested in being added to this list, please see next paragraph.
 
 </aside>
 
@@ -37,6 +37,60 @@ It is possible to customize the list of providers for `clusterctl` by changing t
 
 </aside>
 
+#### Adding a provider to clusterctl
+
+As a Cluster API project, we always have been more than happy to give visibility to all the open source CAPI providers
+by allowing provider's maintainers to add their own project to the pre-defined list of provider shipped with `clusterctl`.
+
+<aside class="note">
+
+<h1>Important! it is visibility only</h1>
+
+Provider's maintainer are the ultimately responsible for their own project.
+
+Adding a provider to the `clusterctl` provider list does not imply any form of quality assessment, market screening, 
+entitlement, recognition or support by the Cluster API maintainers.
+
+</aside>
+
+This is the process to add a new provider to the pre-defined list of providers shipped with `clusterctl`:
+- As soon as possible, create an issue to the [Cluster API repository](https://sigs.k8s.io/cluster-api) declaring the intent to add a new provider;
+  each provider must have a unique name & type in the pre-defined list of providers shipped with `clusterctl`; the provider's name
+  must be declared in the issue above and abide to the following naming convention:
+  - The name must consist of lower case alphanumeric characters or '-', and must start and end with an alphanumeric character.
+  - The name length should not exceed 63 characters.
+  - For providers not in the kubernetes-sigs org, in order to prevent conflicts the `clusterctl` name must be prefixed with
+    the provider's GitHub org name followed by `-` (see note below).
+- Create a PR making the necessary changes to clusterctl and the Cluster API book, e.g. [#9798](https://github.com/kubernetes-sigs/cluster-api/pull/9798),
+  [9720](https://github.com/kubernetes-sigs/cluster-api/pull/9720/files). 
+
+The Cluster API maintainers will review issues/PRs for adding new providers. If the PR merges before code freeze deadline
+for the next Cluster API minor release, changes will be included in the release, otherwise in the next minor
+release. Maintainers will also consider if possible/convenient to backport to the current Cluster API minor release
+branch to include it in the next patch release.
+
+<aside class="note">
+
+<h1>What about closed source providers?</h1>
+
+Closed source provider can not be added to the pre-defined list of provider shipped with `clusterctl`, however, 
+those providers could be used with `clusterctl` by changing the [clusterctl configuration](configuration.md).
+
+</aside>
+
+<aside class="note">
+
+<h1>Provider's GitHub org prefix</h1>
+
+The need to add a prefix for providers not in the kubernetes-sigs org applies to all the providers being added to
+`clusterctl`'s pre-defined list of provider starting from January 2024. This rule doesn't apply retroactively
+to the existing pre-defined providers, but we reserve the right to reconsider this in the future.
+
+Please note that the need to add a prefix for providers not in the kubernetes-sigs org does not apply to providers added by
+changing the [clusterctl configuration](configuration.md).
+
+</aside>
+
 #### Creating a provider repository on GitHub
 
 You can use a GitHub release to package your provider artifacts for other people to use.