Compliance notifications

Compliance Notifications

The Compliance Notifications screen is the control centre for your organisation's automated alert policy. Here, a Data Protection Officer (DPO), compliance manager, or IT administrator decides which compliance events trigger a notification, how that notification is delivered (email or in-app), and who receives it. This is not a personal preference screen — every choice made here applies organisation-wide and directly affects how quickly your teams hear about incidents, overdue tasks, expiring vendor contracts, and changes to your records of processing. If you are preparing for a data protection audit, or rolling out a new compliance programme, this is one of the first screens you should visit.

How to open it

Navigate to Compliance Settings in the left-hand sidebar, then click Notifications by Role in the sub-menu. The page loads at /compliance/settings/notifications.

You need the Compliance Settings — Read permission to view this page, and the Compliance Settings — Edit permission to make changes. If you open the page without the read permission, you will see an access-denied screen instead of the notification table. If you have read access but not edit access, the Edit button is visible but greyed out and cannot be clicked.

What you see

When the page first loads, you land in a read-only overview. The top of the content area shows the heading "Notifications" alongside a small Edit button with a pen icon. Below that is a short paragraph explaining what the notifications configuration controls — useful context for anyone reviewing this screen for the first time or during an audit.

The bulk of the screen is a wide table that spans the full page width. The table is divided into clearly labelled sections — one for each compliance module (for example, ROPA, Assets, Vendors, Incidents, Tasks). Each section has a shaded header row that acts as a visual separator and also contains two "select all" checkboxes. Below each section header, individual notification rows list the specific event types (such as "on create," "on assign," or "on contract expiry"), the recipient group that would receive the alert, and two checkboxes showing whether email and in-app delivery are currently enabled.

In read-only mode, none of the checkboxes respond to clicks — they are there purely to show you the current configuration at a glance. This makes the index page ideal for compliance reviews and audit evidence: you can see the full picture without any risk of accidentally changing something.

Working with this screen

Reviewing the notification configuration before an audit

If you are preparing audit documentation, start here. Open Compliance Settings → Notifications by Role and scan through each section of the table.

For each section header row, the two "select all" checkboxes give you an instant at-a-glance indicator: if the email checkbox in the INCIDENT header row appears checked, every incident event type has email delivery turned on. Be aware, however, that this checkbox uses a strict all-or-nothing logic — if even one notification row in that section has email switched off, the header checkbox will appear unchecked, even if the rest are enabled. Always look at the individual rows beneath the header to confirm the exact configuration.

Once you have verified the settings are correct, you can take a screenshot or export the page for your audit file. No action is required — simply close the page or navigate away.

Setting up or changing notifications for the first time

When you are ready to configure or update the organisation's notification policy, click the Edit button at the top right of the page. (Remember: you need the Compliance Settings — Edit permission to do this.) DPMS navigates you to the edit page, and while the configuration loads from the backend you will briefly see an animated placeholder table. Once the table appears fully, all checkboxes become interactive.

Work through each section in the table. For example, to enable all email alerts for the Incidents module in one step, find the INCIDENT section header row and tick its Email Notifications checkbox. Every incident event underneath will become checked immediately. If you only want to enable email for some incident events but not others, scroll down into that section and tick or untick the individual rows instead.

You can also mix channels: some events might warrant both an email and an in-app notification (for critical events like incident creation), while lower-priority events such as a record status change might only need an in-app nudge to avoid inbox clutter.

When you are satisfied with all your changes across every module, click Save. DPMS sends your updated configuration to the backend. A success toast message confirms the changes have been applied. If something goes wrong on the server side, an error message appears and your changes remain on screen so you can try again.

Heads up: Changes on the edit page are not auto-saved. If you navigate away using the browser back button, close the tab, or let your session expire before clicking Save, all unsaved changes are lost without warning. Always click Save before leaving the edit page.

Enabling all notifications for a single module quickly

A common scenario is a new compliance programme launch where you want to switch on every notification for a specific module — say, Tasks — without touching the others.

• Click Edit to open the edit page.
• Wait for the table to fully load.
• Locate the TASK section header row.
• Click the Email Notifications checkbox in that header row. Every task-related email notification is now enabled in one click.
• Repeat the same step for the In-App Notifications checkbox if you also want in-app alerts for all task events.
• Click Save.

You do not need to scroll through and tick every individual row manually. The section-level checkboxes are designed precisely for this bulk-enable scenario.

Fine-tuning delivery channels for a specific event type

Sometimes the right policy is more nuanced: vendor contract expiry events should send an email to the procurement team, but you do not want them cluttering the in-app notification feed, which you reserve for urgent issues. For this kind of fine-grained control:

• Click Edit.
• Wait for the table to load.
• Scroll to the VENDOR section.
• Find the row for the specific event (for example, on contract expiry).
• Check whether the Email Notifications checkbox is already ticked. If not, tick it.
• Look at the In-App Notifications checkbox for the same row. If it is ticked and you do not want in-app alerts for this event, untick it.
• Continue adjusting other rows in the VENDOR section — or any other section — as needed.
• Click Save when all your changes are in place.

The recipient group shown in the second column (for example, "Procurement Team") is informational — it tells you who will receive the notification when the event fires. Recipient groups are defined in the backend configuration and cannot be changed from this screen.

Returning to read-only view without saving

If you open the edit page and decide not to make changes after all, click the back arrow at the top left of the edit page. This returns you immediately to the read-only notifications index. No data is saved and no API call is made. Any checkbox changes you made on the edit page are discarded silently — there is no confirmation dialogue.

Field reference

Element Type / Option — The name of the module (ROPA, Asset, Vendor, Incident, Task) and the specific event within that module (for example, "on create," "on overdue," "on contract expiry"). These rows are fixed and controlled by the backend configuration. You cannot add or remove event types from this screen.

Recipient Group — The category of users who will receive the notification when the event fires. Examples include "DPO Admins" (all users with a DPO or administrator role), "Assigned Users" (only the person(s) assigned to the record), "Task Owner," and "Procurement Team." This column is display-only — you cannot change which group receives a given notification type from this screen.

Email Notifications — A checkbox that enables or disables email delivery for this event. When checked, the system will send an email to the relevant recipient group when the event occurs. When unchecked, no email is sent — this is a deliberate choice, not an error.

In-App Notifications — A checkbox that enables or disables in-app alerts (the bell or badge icon inside DPMS) for this event. In-app notifications stay within the DPMS environment and do not require an email address to reach their recipient.

How this connects to the rest of DPMS

The Compliance Notifications screen sits inside Compliance Settings, alongside other organisation-level configuration pages such as group management, tags, and statuses. The settings you define here are not isolated — they cascade across every module in the system.

Specifically:

• ROPA (Records of Processing Activities): Creation, update, deletion, assignment, and DPO review events only generate alerts if the corresponding ROPA notification rows are enabled here.
• Assets: Events such as new asset creation, risk score changes, and assignment only reach their audience if the Asset section is configured.
• Vendors: Contract expiry alerts — critical for organisations that rely on DPMS to flag upcoming renewals — are entirely controlled by the Vendor section. If these rows are switched off, no automatic warning will fire when a vendor contract is about to expire.
• Incidents: Incident creation and assignment notifications are the fastest signal your team will have of a potential breach. These events are gated entirely by the Incident section of this table. Keeping those rows enabled is a key part of timely breach response under GDPR Article 33.
• Tasks: Task assignment, completion, and overdue alerts across all modules only reach their intended recipients if the Task rows are enabled here.

If a notification type is not enabled on this screen for either channel, no alert will be sent — regardless of the event occurring or any individual user's own preferences. This screen is a prerequisite for the automated notification flow that keeps your compliance programme running.

After completing your configuration here, verify that the relevant users are members of the appropriate recipient groups (managed in the Groups section of Compliance Settings) so that alerts actually reach the right people.

Tips & common pitfalls

Tip: If you want a quick audit-ready snapshot of the current configuration, open the read-only index page, take a screenshot, and save it to your audit file. The read-only view reflects the configuration as it was when the server rendered the page — always refresh the page first to ensure you are seeing the latest saved settings.

Heads up: The "select all" checkboxes in section header rows do not show an indeterminate state. If eight of nine notification types in a section have email enabled, the section header checkbox still appears unchecked — because it requires all rows to be checked before it shows as checked. Always inspect the individual rows if you are unsure of the true state.

• Changes are not auto-saved. Every checkbox change on the edit page updates only what DPMS holds in memory in your browser session. Close the tab or let your session expire before clicking Save, and your work is gone. Make it a habit to click Save before navigating away.
• You cannot add or remove notification event types from this screen. The rows in the table are defined in the backend configuration. If you expect a notification type (such as "on risk change" for assets) but it does not appear, the absence is in the backend setup — contact your system administrator or implementation team.
• The recipient group labels are translations of internal keys. The text you see ("DPO Admins," "Task Owner," etc.) is a human-readable label. If a label appears missing or shows something like risk_managers with underscores, the notification will still fire correctly to the right group — only the display in this table is affected.
• Wait for the table to fully load on the edit page before clicking Save. While the configuration is loading, the table shows an animated placeholder. If you click Save before the table has finished loading and the checkboxes have settled into their saved state, you may inadvertently overwrite your existing settings with empty defaults. Wait until every row is visible and the checkboxes reflect the correct saved values before making changes.
• Reload the page before an audit review. The read-only index page shows data from the moment the server rendered it. If another administrator saved changes in a different browser session, you will not see them until you refresh. Always press reload before capturing screenshots for an audit.