Incidents & Breaches

The Incidents & Breaches screen is the central hub for managing data incidents inside DPMS — from the moment an issue is first reported to the moment it is formally resolved. Whether you are handling a stolen laptop, an accidental email disclosure, or a full-scale ransomware attack affecting personal data, this screen gives you a structured record that captures what happened, when it was reported, who is responsible, what remediation steps are in progress, and what the outcome was. For DPOs and compliance officers, that structured record is exactly what a supervisory authority expects to see when you notify them under GDPR Article 33.

Within the broader DPMS ecosystem, Incidents & Breaches sits at a crossroads: a single incident record can link to Assets (the systems involved), Risk Assessments, remediation Tasks, and formal review Workflows — all without leaving the screen. The built-in Activity Log captures every change to the record with a timestamp and the name of the person who made it, giving you a verifiable audit trail that would be extremely difficult to replicate in email or a spreadsheet.

How to open it

In the main left sidebar, click Incidents. The list page opens immediately — no sub-menus required. You need at least read access to Incidents to see this menu item; if it is missing from your sidebar, ask your DPMS administrator to check your permissions. Users who have been granted access only to records assigned to them will still see the same list view, but the table will only show their own records.

What you see

The screen has two main views: the list page and the detail view.

On the list page, the top of the content area shows the page title followed by a row of status-filter tabs — All, Draft, Processing, Active, Inactive, Resolved, and Review — that let you instantly narrow the table to one stage of the incident lifecycle. The table below those tabs shows each incident's name, reporting date, incident date, and a coloured status badge. A blue Create button sits in the top-right corner, and an export button nearby lets you download the current list to Excel or JSON.

Opening any row takes you to the detail view, where the screen divides into three zones. On the far left is a thin strip with a small circle icon that expands or collapses a vertical tab menu. That tab menu — General, Log, Documents, Tasks, Assessments, and Review & Approvals — lets you navigate between every aspect of the incident. Across the top of the main content area runs a breadcrumb bar showing where you are, with small arrow icons to jump to the previous or next incident without going back to the list. Just below the breadcrumbs is the sticky header: a horizontal band that always stays visible and holds the responsible person selector, the status dropdown, the priority selector, and the dates when the record was last updated and last reviewed.

Working with this screen

Registering a new incident for the first time

When an incident comes to your attention — say, a stolen employee laptop — navigate to Incidents in the sidebar and click the blue Create button. A small dropdown appears; select Create Incident. The creation form opens on the General tab, pre-populated with today's date in the Reporting Date field.

Fill in the Name (something clear and searchable, like "Stolen Laptop — HR Department"), the Incident Date (when it actually happened), and a Description summarising what you know so far. Set the Status to Processing if the investigation is already underway, or leave it as Draft if you are still gathering facts. Assign a Responsible Person — usually yourself or the lead investigator. When you are happy with the core details, save the form. DPMS creates the record and takes you straight to the new incident's detail view.

From there, you can immediately start building out the full picture: switch to the Tasks tab to link any remediation tasks already created in DPMS, go to Assessments to connect a risk assessment, or visit Documents to attach relevant policies. If your organisation uses formal review workflows, head to Review & Approvals and trigger a workflow to get your manager's sign-off before you notify the supervisory authority.

Tip: Add all your log entries and link all related tasks and assessments before you change the status to Resolved. Once you mark an incident as Resolved, the entire record becomes read-only — you will not be able to add a final log entry or unlink anything without temporarily setting the status back to Active.

Monitoring open incidents day to day

A common morning routine for a compliance officer is to click the Processing tab on the list page to see only the incidents that are actively being investigated. If you manage many incidents at once, the All tab with the status badges gives you a quick colour-coded overview.

Open any record that needs attention. In the sticky header, you can reassign the incident to a different responsible person simply by clicking the name field and choosing someone new — the change is saved the moment you confirm, with no separate Save button needed. The same instant-save behaviour applies when you change the Status or the Priority.

To document investigation progress, click the Log tab and use the add button within the log table to create a new log entry. Each entry captures a name, the date of the event you are documenting, who wrote it, and a free-text description. These entries build a chronological investigation journal and are permanently attached to the incident record — making it straightforward to reconstruct the timeline later.

If you need to step through several incidents in sequence — for example, during a quarterly review — use the left and right arrow icons in the breadcrumb bar. They navigate directly to the previous or next incident in whatever filtered list you were viewing, so you never need to keep clicking back and forth to the index.

Closing a resolved incident

Once remediation is confirmed and all documentation is complete, open the incident and use the Status dropdown in the sticky header to change the status to Resolved. DPMS saves the change immediately. From that point on, the record is fully read-only: checkboxes disappear from all the linked-object tables, trailing action buttons are disabled, and you will see a not-allowed cursor if you try to interact with a table. This lock is intentional — it preserves the integrity of the audit record.

Before navigating away, click the clock icon in the top-right of the content area to open the Activity Log drawer. This slide-in panel shows every change ever made to this record — who changed what and exactly when — in reverse chronological order.

Scroll through the drawer to confirm that the status change to Resolved is recorded with the correct timestamp. This is the evidence you would attach to a supervisory-authority notification or an internal audit report.

Reviewing incidents as an auditor

If you have been granted read-only access, the experience is largely the same — you can browse every record, filter by status, and open individual incidents — but all editing controls are disabled. The Edit button on the General tab shows a tooltip explaining you do not have edit permission. The status, priority, and responsible person controls in the sticky header are greyed out and unclickable.

Use the prev/next arrows in the breadcrumb to step through incidents sequentially, and open the Activity Log drawer on each one to verify the chain of custody. This is often exactly what an external auditor needs: a complete, tamper-evident record showing who created the incident, who changed its status, and when it was closed.

Heads up: The Activity Log clock icon is hidden if you are viewing a record that has been shared with your organisation from another DPMS tenant. This is by design — the audit trail is only available to the organisation that owns the record.

Field reference

• Name — The title of the incident. Required. Shown in the table and in the breadcrumb. Should be descriptive enough that anyone in your organisation can identify the event at a glance.
• Incident Date — The date and time when the incident actually occurred or was first discovered. Distinct from the Reporting Date. Required for most reporting obligations.
• Reporting Date — The date the incident was formally reported within your organisation. Pre-populated with the current date and time when you create a new record; you can adjust it if the formal report was submitted at a different time.
• Status — The lifecycle stage of the incident: Draft, Processing, Active, Inactive, Resolved, or Review. Setting to Resolved locks the entire record. Your DPMS administrator may have added custom status options that also appear here.
• Priority — How urgent or severe the incident is (Low, Medium, High, Critical). Used to triage and sort incidents. Not required, but strongly recommended for high-severity breaches.
• Responsible Person — The person (or persons) accountable for managing this incident. Can be updated at any time from the sticky header as long as the record is not Resolved.
• Description — A free-text, rich-text field for the full narrative of the incident. Can be edited inline on the General tab without navigating to the full edit form, as long as the record is not Resolved.

How this connects to the rest of DPMS

Once an incident is created, it becomes a hub that other modules point to. Remediation Tasks you link here will show the incident as their parent context; Risk Assessments connected here let you track whether the breach revealed a gap that needs formal assessment; Documents such as notification letters or post-incident reports can be attached directly.

The Review & Approvals tab connects the incident to DPMS's workflow engine. If your organisation has configured review templates, you can trigger a multi-step approval chain — for example, requiring sign-off from your DPO and Legal before you send an Article 33 notification — entirely from within the incident record.

After closing an incident, consider navigating to the linked Assessments to update any residual risk scores, and to the linked Tasks to confirm all remediation actions are marked complete. The incident record itself should be treated as a permanent archive: even after it is Resolved, it remains searchable and accessible for future audits.

Tips & common pitfalls

Heads up: Setting the status to Resolved immediately locks all tabs. If you realise you need to add a final log entry after resolving, you must temporarily change the status back to Active, make your addition, and then set it to Resolved again.

Tip: Before exporting the incident list for a board report or regulatory submission, switch to the All tab so that the export captures every record regardless of status.

• The Import option is invisible if you lack import permission. If a colleague tells you they can import incidents from JSON and you cannot see that option in the Create dropdown, ask your administrator about import access — the option is hidden entirely rather than greyed out, so there is no visible clue that it exists.
• Prev/Next navigation is based on the filter you had active when you opened the detail. If the arrows skip a record you expected to find, it may have a different status and was filtered out of the list you started from. Go back to the list, switch to All, and reopen the record.
• The Required Action sub-tab only appears when there is an active workflow. If you open Review & Approvals and see only the Overview table, either no workflow has been triggered yet or all previous workflows are already complete or cancelled. Use the trigger button in the Overview table to start a new review cycle.
• Custom status values configured by your administrator appear alongside the default statuses in both the filter tabs and the status dropdown. If you see unfamiliar status names, check with your DPMS administrator to understand how they fit into your organisation's incident lifecycle.
• The Activity Log is separate from Log Entries. The Log tab (Log Entries) is where you manually write narrative updates about the investigation. The Activity Log (the clock-icon drawer) is the automatic audit trail DPMS maintains of every field change. Both are important, but they serve different purposes.