diff --git a/README.md b/README.md
index 638f66a0..5c866ee2 100644
--- a/README.md
+++ b/README.md
@@ -39,6 +39,7 @@ See issue collection [MWDI v2.0.1_spec](https://github.com/openBackhaul/MicroWav
 MWDI v2.0.1 also adds the following changes to notification handling diverging from v2.0.0:
 - (1) Controller notifications shall not be pulled from Kafka, but again pushed to MWDI by NotificationProxy
 - (2) Device and alarm notifications are to be pulled from Kafka from two separate topics
+- (3) Pulling of notifications from Kafka and processing them can be turned on/off via a profileInstance
 
 *Details*:  
 - for (1) the following changes were applied:
diff --git a/spec/MicroWaveDeviceInventory+config.json b/spec/MicroWaveDeviceInventory+config.json
index 2e61d308..5c628acf 100644
--- a/spec/MicroWaveDeviceInventory+config.json
+++ b/spec/MicroWaveDeviceInventory+config.json
@@ -470,6 +470,22 @@
             }
           }
         },
+        {
+          "uuid": "mwdi-2-0-1-string-p-005",
+          "profile-name": "string-profile-1-0:PROFILE_NAME_TYPE_STRING_PROFILE",
+          "string-profile-1-0:string-profile-pac": {
+            "string-profile-capability": {
+              "string-name": "kafkaNotificationReceiptAndProcessingSwitch",
+              "enumeration": [
+                "on",
+                "off"
+              ]
+            },
+            "string-profile-configuration": {
+              "string-value": "on"
+            }
+          }
+        },
         {
           "uuid": "mwdi-2-0-1-mapping-p-000",
           "profile-name": "regex-pattern-mapping-profile-1-0:PROFILE_NAME_TYPE_REGEX_PATTERN_MAPPING_PROFILE",
diff --git a/spec/MicroWaveDeviceInventory+profileInstances.yaml b/spec/MicroWaveDeviceInventory+profileInstances.yaml
index 654d743b..17dfa8e5 100644
--- a/spec/MicroWaveDeviceInventory+profileInstances.yaml
+++ b/spec/MicroWaveDeviceInventory+profileInstances.yaml
@@ -263,6 +263,17 @@ profile-instances:
     configuration:
       string-value: 'delete-on-disconnect'
 
+  - profile-name: 'StringProfile'
+    uuid: 'mwdi-2-0-1-string-p-005'
+    capability:
+      string-name: 'kafkaNotificationReceiptAndProcessingSwitch'
+      enumeration:
+        - 'on'
+        - 'off'
+      #description: 'This profileInstance allows toggeling the receipt/fetching of notifications from Kafka and processing them on/off. Default is on.'
+    configuration:
+      string-value: 'on'
+
   - profile-name: 'RegexPatternMappingProfile'
     uuid: 'mwdi-2-0-1-mapping-p-000'
     capability:
diff --git a/spec/additionalDescription/CyclicControlConstructRetrievalProcess.md b/spec/additionalDescription/CyclicControlConstructRetrievalProcess.md
index cd612fdd..60b74c07 100644
--- a/spec/additionalDescription/CyclicControlConstructRetrievalProcess.md
+++ b/spec/additionalDescription/CyclicControlConstructRetrievalProcess.md
@@ -186,6 +186,8 @@ Depending on the respective notification the cached ControlConstruct is modified
 
 Also note that in the past MWDI had a subscription to NotificationProxy, which did push the notifications to MWDI. For this, NP called the *regard*-services each time a new notification was pushed, thereby creating a new http session every time. With MWDI 2.0.0 this approach has been changed. MWDI pulls the messages from Kafka and processes the notifications then directly. For this, MWDI executes the functionality from *regard*-services internally (i.e. without opening a new http-session), which is why the *regard*-services along with their related forwardings are kept in the specification, but marked as deprecated.
 
+Polling notifications from Kafka can be switched on/off via profileInstance *kafkaNotificationReceiptAndProcessingSwitch*. If it is turned *off*, no notifications shall be fetched and processed until it is changed back to *on* (default).
+
 **User-initiated updates of ControlConstruct parts**  
 Certain parts of the ControlConstruct can be updated upon “user” demand. I.e. if another application calls a *live* path for e.g. the air interface capabilities, they are retrieved from the device and then the air interface capabilities inside the cached ControlConstruct are updated with the newly retrieved information. The other parts of the ControlConstruct are not updated by this.
 
diff --git a/spec/diagrams/01x_NotifcationPollingFromKafkaAndProcessing.plantuml b/spec/diagrams/01x_NotifcationPollingFromKafkaAndProcessing.plantuml
index 223736d5..d2c1f823 100644
--- a/spec/diagrams/01x_NotifcationPollingFromKafkaAndProcessing.plantuml
+++ b/spec/diagrams/01x_NotifcationPollingFromKafkaAndProcessing.plantuml
@@ -41,6 +41,13 @@ end note
 mwdi -> kafkaAlarm: {topicName, brokerId, groupId, clientId} (apiKeyAuth)
 
 == cycically poll new notifications and process them ==
+note over mwdi #LightPink
+  Only poll deviceChangeNotifications and deviceAlarmNotifications
+  while profileInstance
+  <i>kafkaNotificationReceiptAndProcessingSwitch</i> == "on",
+  when set to "off" no polling to be executed
+end note
+
 note over mwdi
 <u>deviceChangeNotificationPolling</u>
   Continuously poll all new device change notifications from Kafka.
diff --git a/spec/diagrams/01x_NotificationPollingFromKafkaAndProcessing.png b/spec/diagrams/01x_NotificationPollingFromKafkaAndProcessing.png
index 717745d1..1ae1e7a1 100644
Binary files a/spec/diagrams/01x_NotificationPollingFromKafkaAndProcessing.png and b/spec/diagrams/01x_NotificationPollingFromKafkaAndProcessing.png differ