diff --git a/doc/contributing/submitting-changes.xml b/doc/contributing/submitting-changes.xml
index 14155021f614..6a8b4e0b249e 100644
--- a/doc/contributing/submitting-changes.xml
+++ b/doc/contributing/submitting-changes.xml
@@ -228,6 +228,33 @@ Additional information.
    </listitem>
   </itemizedlist>
  </section>
+ <section xml:id="submitting-changes-submitting-security-fixes">
+  <title>Submitting security fixes</title>
+
+  <para>
+   Security fixes are submitted in the same way as other changes and thus the same guidelines apply.
+  </para>
+
+  <para>
+   If the security fix comes in the form of a patch and a CVE is available, then the name of the patch should be the CVE identifier, so e.g. <literal>CVE-2019-13636.patch</literal> in the case of a patch that is included in the Nixpkgs tree. If a patch is fetched the name needs to be set as well, e.g.:
+  </para>
+
+<programlisting>
+   (fetchpatch {
+     name = "CVE-2019-11068.patch";
+     url = "https://gitlab.gnome.org/GNOME/libxslt/commit/e03553605b45c88f0b4b2980adfbbb8f6fca2fd6.patch";
+     sha256 = "0pkpb4837km15zgg6h57bncp66d5lwrlvkr73h0lanywq7zrwhj8";
+   })
+  </programlisting>
+
+  <para>
+   If a security fix applies to both master and a stable release then, similar to regular changes, they are preferably delivered via master first and cherry-picked to the release branch.
+  </para>
+
+  <para>
+   Critical security fixes may by-pass the staging branches and be delivered directly to release branches such as <literal>master</literal> and <literal>release-*</literal>.
+  </para>
+ </section>
  <section xml:id="submitting-changes-pull-request-template">
   <title>Pull Request Template</title>