diff --git a/beps/0001-notifications-system/README.md b/beps/0001-notifications-system/README.md
index c25d78b5df..5b37016a10 100644
--- a/beps/0001-notifications-system/README.md
+++ b/beps/0001-notifications-system/README.md
@@ -110,7 +110,6 @@ The notification backend stores notification using the [database service](https:
   - Topic (optional)
   - Scope (optional)
   - Icon (optional)
-  - Image URL (optional)
 
 The recipients is **not** a list of users, but rather a filter that describes who should receive the notification. It must be possible to evaluate this filter in a database query, so that we can efficiently fetch all notifications for a given user. The same filter will also be used by the signal backend to determine which users should receive a signal.
 
@@ -136,7 +135,7 @@ The idea of scope is to be able to reuse notifications about same information fo
 
 The timestamp of notification creation is auto-generated by the notifications backend at the time of receiving a request to create the notification.
 
-The icon and image URL are optional and is meant to improve UX. A string referencing an icon name from MUI icon library of a defined version. If missing, it will be determined from the severity.
+The icon is optional and is meant to improve UX. A string referencing an icon name from MUI icon library of a defined version. If missing, it will be determined from the severity.
 
 The link is a relative or absolute URL. As an example, it can be used:
 
@@ -265,7 +264,6 @@ Example signal payload for a new notification:
 #### Future considerations
 
 - Add icon for the notification request (for UX purposes)
-- Add image url for the notification request (for Web Notification API purposes)
 - Broadcast messages are to be saved to a separate table for performance reasons
 - OpenAPI tooling is taken into use for the notification router and client