Browse incidents

Browse Incidents

The Incidents screen is the central hub where Data Protection Officers, compliance managers, and risk managers keep track of every data protection incident that occurs in your organisation. Whether you're dealing with a confirmed personal data breach, a near-miss, or an internal security event, this screen gives you a single, structured place to record it, monitor its progress, and drive it through to resolution — replacing the spreadsheets and email chains that make GDPR compliance so difficult to manage. Under GDPR, your organisation must document all personal data breaches, assess their severity, and in serious cases notify your supervisory authority within 72 hours; the Incidents module is built to support exactly that obligation.

How to open it

Navigate to Incidents in the left-hand sidebar. It appears as a first-level navigation item and is available from any screen in DPMS. You need at least read access to incidents to see this page. Users with full read access can see all incidents in the organisation; users who only have restricted read access will see only those incidents where they are listed as a responsible person.

What you see

When the page loads, you are greeted by the standard DPMS list layout. A horizontal action bar runs across the top of the content area, with a Create button on the right-hand side alongside export controls for downloading the list as JSON or Excel. Below the action bar sits a row of status tabs — All, and one tab for each stage of the incident lifecycle — which let you instantly filter the visible list by status.

The bulk of the screen is occupied by a table listing every incident your organisation has recorded. Each row shows four columns: the incident's Name, its Reporting Date (when it was formally reported internally), its Incident Date (when it actually happened), and its current Status. Statuses are colour-coded so you can spot open or critical incidents at a glance. You can scroll to the bottom of the table and additional records load automatically — there is no "next page" button to click.

At the left edge of each row is a checkbox for bulk operations, and at the right edge is a three-dot menu for quick row-level actions like deleting a record.

Working with this screen

Recording a newly discovered data breach

When a colleague reports a potential personal data breach — say, a laptop containing unencrypted customer data has been left on a train — you need to open a formal incident record immediately. Time matters under GDPR.

Click the Create button in the top-right corner of the action bar. A small dropdown menu appears. Select Create Incident. DPMS navigates you to the incident creation form. From there, fill in the incident's name (for example, "Lost Laptop — Customer Data"), set the Incident Date to the date the event occurred, confirm the Reporting Date as today (the date you were first notified internally), assign a responsible person, and choose a status such as "Processing" to signal that the incident is under active investigation. Once you save the record, it appears in the list on the All tab with a status of Processing, and your team can begin working through it from the detail screen.

Heads up: The Incident Date and Reporting Date are two separate fields for a reason. Regulators under GDPR care about both: how long passed between the event and its discovery, and how long between discovery and notification. Fill in both fields accurately from the start — correcting them later can create audit trail inconsistencies.

Reviewing open incidents to prepare a regulatory report

At the end of each quarter, or whenever you need to update your supervisory authority, you will want to focus on incidents that have not yet been closed.

Click the tab for your "Processing" (or equivalent open) status. The table immediately updates to show only incidents at that stage. Review each row — the Incident Date and Reporting Date columns tell you how old each record is. If you notice incidents that appear to have stalled, click that row to open the detail view, review the log entries, and follow up with the responsible person assigned. When you are ready to export, click the Excel (XLSX) icon in the action bar. A spreadsheet is downloaded to your device containing every incident currently visible in the filtered table. You can attach this directly to your regulatory submission or quarterly board report.

Tip: Always check which tab you are on — and whether any search filters are active in the filter bar — before exporting. The export reflects exactly what you see on screen. If you accidentally export while the "Processing" tab is active, resolved incidents will not be included.

Searching for incidents linked to a specific system or person

Following a security assessment, a risk manager may need to locate every incident that involves a particular CRM system or that was assigned to a specific responsible person.

Use the search and filter bar below the action bar. Type a keyword (such as the system name) or build a structured filter (for example, filtering by responsible person name). The table updates in real time to show only matching incidents. Click any row to open the full detail view, where you can link new risk assessments, add log entries, or update the status. If you applied a filter and then clicked through to a detail page, the filter is still active when you return — the back arrow on the detail page brings you back to the same filtered list, and the Previous/Next record arrows on the detail page step through the filtered results, not the full list.

Bulk-importing historical incidents from another system

If your organisation is migrating from a legacy system, or if you have a batch of historical incident records prepared as a JSON file, you can import them all at once rather than creating them one by one.

Click the Create button, then select Import from the dropdown. Your operating system's file picker opens. Select the JSON file you have prepared and confirm. A loading indicator briefly appears across the table while the upload processes. When it completes, the list reloads and your imported incidents are visible in the All tab. Switch to the Resolved tab to verify that incidents previously marked as resolved have come through with the correct status.

Heads up: Importing does not check for duplicates. If you import the same file twice, you will end up with duplicate records. Always verify the list after importing before running the process a second time.

Cleaning up test records in bulk

During system onboarding, compliance teams often create test incidents to explore the workflow. Once you are ready to go live, you can remove them all at once.

Tick the checkbox on each row you want to delete. A "select all" checkbox at the top of the column lets you select every visible row at once — if you have a status filter active, this selects only the filtered records, not every incident in the database. Once you have made your selection, the bulk delete action becomes available at the bottom of the page. Confirm the deletion when prompted.

Field reference

Name — The title of the incident. This is the primary identifier that appears in the list and in linked records throughout DPMS. Supports multiple languages if your organisation operates in more than one locale.

Incident Date — The date (and optionally time) when the incident actually occurred. Under GDPR, regulators need to know when the breach took place. Leave blank only if the date is genuinely unknown at the time of first recording; update it as soon as it is established.

Reporting Date — The date on which the incident was formally reported internally (for example, when the IT team first told the DPO). DPMS defaults this to today's date and time when you create a new record. Correct it if the internal report was actually made earlier — the time between discovery and internal reporting is a factor regulators may examine.

Status — A configurable label showing where the incident sits in your lifecycle. Standard values include Processing (under active investigation) and Resolved (closed). Custom statuses can be configured in your Compliance Settings. Be aware that once an incident is marked Resolved, the edit controls on its detail screen are locked; you must first change the status back to a non-resolved value before you can add further log entries or make changes.

How this connects to the rest of DPMS

The Incidents list is the gateway to all individual incident records. You cannot reach an incident's detail page — where you add log entries, link tasks, attach documents, connect assessments, or trigger workflow steps — without going through this list (or using a direct URL). Every workflow step, every piece of documentation, and every compliance response to a breach is managed from those detail pages, which you open by clicking a row here.

Once you have opened an incident's detail page, the Previous and Next record arrows let you move through incidents in the order that was active in this list when you clicked through — including any filters you had applied. This makes it efficient to work through a batch of related incidents without returning to the list each time.

After recording a new incident here, your natural next steps are to open the detail page, fill in the full description, assign responsible persons, and begin adding log entries. You should also consider linking the incident to any relevant risk assessments or data protection impact assessments, and creating remediation tasks to drive the response forward. All of these connections are managed from the incident's detail screen, not from this list.

The Tasks module, the Assessments module, and the Documents and Policies module all allow you to link back to incidents, so that anyone working on a related task or assessment can see the incident context without navigating here separately.

Tips & common pitfalls

Tip: If a colleague says "I can't see any incidents," the most likely explanation is that they have restricted read access rather than full read access. Users with restricted access see only incidents where they are listed as a responsible person. Check their permission settings before concluding that records are missing.

Heads up: The Import option in the Create dropdown is visible to all users, but clicking it has no effect if the user does not have import permission. There is no error message — the file picker simply does not open. If someone reports that Import "doesn't work," check their permissions rather than assuming a technical fault.

• Resolved incidents cannot be edited. As soon as an incident's status is changed to Resolved, all edit controls on the detail screen are disabled. To add a new log entry or correct information, you or a user with edit permission must first change the status back to an active value.
• Active filters persist as you navigate. If you searched for incidents by a responsible person's name, applied a status filter, or switched to a specific tab, that filter state is preserved when you return from a detail page. This is useful for batch review, but can be surprising — and it affects exports. Always glance at the filter bar before downloading a report.
• Your last-used tab is remembered. When you return to the Incidents list from a detail page, DPMS restores whichever tab you were on before. If you were on the "Processing" tab, you will return to it — not to "All." This is intentional, but can cause confusion if you expect to see the full list.
• Export reflects the current view, not all records. The JSON and Excel exports download only what is currently visible in the filtered, tabbed list. If you need a complete export for archiving purposes, make sure you are on the All tab with no active search or filter criteria before clicking the export button.