diff --git a/content/guides/component_guide.md b/content/guides/component_guide.md
index 08d5731440ef272dd4b19f18d6e9188f940b8b84..024639dd4ee6158f884be55195637bd7a7c24771 100644
--- a/content/guides/component_guide.md
+++ b/content/guides/component_guide.md
@@ -790,12 +790,32 @@ license, or fails to process it correctly, there are three ways to fix this:
    Please also verify `debian/copyright` specifies the correct license, and if
    it doesn’t, submit a patch to Debian.
 
+   The `license` statement should be used when the license scan fails to determine a
+   license (reporting it as as `UNKNOWN`), while `override-license` should be used
+   when it reports an incorrect one.
+
+   {{% notice warning %}}
+   Since `override-license` will override the reported license it should be
+   used with caution and only if it is needed.
+   {{% /notice %}}
+
 2. Add the file to the list of ignored files,
    `debian/apertis/copyright.whitelist`. This file is formatted the same way as
    `gitignore`, please refer to the
    [gitignore](https://manpages.debian.org/buster/git-man/gitignore.5.en.html)
    manpage for more information.
 
+   This approach is useful in cases where a file has a license unsuitable for
+   Apertis but which won't affect the license of the generated package. A
+   common example of this situation are the tests that run at build time, which
+   will not be part of the binary package.
+
+   {{% notice note %}}
+   The whitelisting will allow license information to be
+   stored in the report, which could potentially be not suitable for Apertis,
+   while not raising an error on the CI pipeline.
+   {{% /notice %}}
+
 3. If the file is under a license not suitable for Apertis, it can be removed
    from the package by either repackaging the tarball or patching it out, in
    which case the scanner will not take it into account.