Edit an incident

Update the analysis, status and linked logs of an existing incident.

Editing an Incident

The Edit Incident screen is where all the real work of incident response happens. When your organisation discovers a potential personal data breach, a security near-miss, or any other event that needs to be tracked under data protection law, this screen is where you record what happened, who is responsible, what actions were taken, and how the incident was ultimately resolved. It sits at the heart of DPMS's incident management workflow, connecting the incident record to tasks, documents, assessments, and formal review workflows — so that when a regulator or auditor asks for evidence of how you handled a breach, everything is in one place.

How to open it

Navigate to Incidents in the main left-hand sidebar. Click any incident row in the index to open its Detail screen, then click the Edit button (pencil icon) or the Edit General link in the detail view header. Alternatively, click the Create button on the Incidents index page to open the same form for a new incident.

Permission note: You need either full incident editing rights or "edit only assigned" rights (which lets you edit incidents where you are listed as a responsible person). Creating a new incident requires create permission. The Trigger Workflow tab additionally requires workflow assignment rights. If you don't have the necessary permission, DPMS shows an access denied page instead of the form.

Screenshot

What you see

The screen follows DPMS's standard two-panel layout. On the far left is a collapsible navigation panel — clicking the small circle icon at the very left edge will hide or show it, giving you more horizontal room for the form when you need it. Your preference is remembered across sessions.

At the top of the main content area sits a breadcrumb trail: Incidents › [Incident Name] › [Current Tab]. Left and right chevron arrows let you jump directly to the previous or next incident in your current filtered list, which is handy when you are reviewing a batch of records without having to return to the index each time.

Below the breadcrumb, the form is organised into tabs shown in the left panel: General, Documents, Tasks, Assessments, Log, Manage Access, Trigger Workflow, and Overview. Only one tab is active at a time. Each tab has its own Save button at the bottom, and a Back/Cancel link that returns you to the incident's detail view without saving any unsaved changes.

Working with this screen

Recording a new incident for the first time

When you click Create on the Incidents index, the form opens on the General tab with empty fields. Start at the top of the form:

Name — Type a clear, searchable title such as "Unauthorised customer data export — Sales dept, March 2024". This field supports multilingual input; if your organisation uses DPMS's automatic translation feature, an AI translate button appears next to the field.
Responsible person(s) — Use the picker in the header action area to assign one or more team members who are accountable for this incident. Responsible persons appear in reports and filters across DPMS, and — importantly — users with "edit only assigned" rights can only access incidents where they appear in this list.
Status — The dropdown defaults to a "Processing" status for new incidents. Leave this as-is until the incident has been formally resolved. You can also select any custom statuses your organisation has configured.
Incident Date — Pick the date and time when the incident actually occurred. This is critical for regulatory reporting: GDPR requires you to notify the supervisory authority within 72 hours of becoming aware of a breach, so accurate dates are essential evidence. You can leave this blank initially if the occurrence date is unknown.
Reporting Date — This field automatically defaults to the current date and time when you create a new incident, reflecting the moment of reporting. Adjust it if the formal reporting happened at a different time.
Description — Write a detailed narrative: what happened, what data was affected, how the incident was discovered, and what immediate steps were taken. This text forms the core of the incident record.

Once you are satisfied with the General tab details, click Save. DPMS creates the incident and redirects you to the new incident's Detail screen. From there, you can return to the Edit form to fill in the remaining tabs.

Linking supporting documents, tasks, and assessments

After saving the General tab, use the other tabs to build a complete evidential record:

Documents tab: Click into the Documents tab and use the link button to search your document library. Attach relevant policies (for example, your "Data Breach Response Procedure") or any other supporting material. Saving sends the link to DPMS, and the document will appear in the linked documents list. You can also click any document row to navigate directly to its full detail screen.

Tasks tab: Switch to the Tasks tab to attach remediation tasks — for example, "Notify affected data subjects" or "Patch the security vulnerability". If these tasks already exist in the DPMS task library, search for and link them here. Each linked task shows the responsible person(s) and due date at a glance. Clicking a task row opens its full detail screen in the Tasks module.

Assessments tab: If you triggered a Data Protection Impact Assessment (DPIA) or other compliance assessment as part of your incident response, link it here. This creates a formal, auditable connection between the incident and the risk evaluation. If your organisation later needs to demonstrate that the incident was properly assessed, this link is the evidence.

For all three tabs, click Save after making changes. Each save sends the updated links to DPMS. When the incident's status is set to "Resolved", all three tabs switch to read-only mode — checkboxes disappear, action buttons are disabled, and the cursor changes to indicate that no further changes are possible.

Building the audit trail with log entries

The Log tab is where you create the timestamped record of everything that happened during incident response. Think of it as an incident diary: each entry captures a specific action, notification, or decision with the exact date and time it occurred.

To add a new log entry:

Navigate to the Log tab on the Edit form.
Fill in the Name field with a short title, such as "DPA notification submitted".
Set the Date — this defaults to the current date and time, which is correct if you are logging something happening right now.
Write a Description explaining exactly what happened: "Submitted Article 33 notification to the supervisory authority via the online portal. Reference number: [xxx]."
Click Save.

The entry is saved and becomes part of the chronological audit trail. Entries are always displayed in the order they were created, oldest first, so the Log tab always tells the incident story in sequence. Once the incident is Resolved, you can no longer add log entries — if you need to add a final note, do it before changing the status.

Triggering a formal review workflow

When your incident response is nearing completion and you want a second set of eyes before closing the record, use the Trigger Workflow tab to start a structured approval process.

Navigate to the Trigger Workflow tab. (If you don't see this tab or see an access denied message, your account does not have workflow assignment rights — speak to your DPMS administrator.)
Select the appropriate workflow template from the available list — for example, "Incident Closure Review".
Configure the required approver(s) and any other settings the workflow asks for.
Click Save to start the workflow.

Once triggered, the assigned reviewers receive a notification. They use the Overview tab on the incident to complete their required action — approving, rejecting, or providing input. You can monitor the workflow's progress from the Overview tab at any time. Only when the workflow concludes can you safely move the incident to a "Resolved" status and close it.

Restricting access to a sensitive incident

If an incident involves particularly sensitive data — for example, HR or health information — you can restrict which DPMS users can see it.

Open the incident's Edit form and navigate to the Manage Access tab.
Use the audience selector to find the user group(s) or individual users who should have access. Assign read or write access as appropriate.
Click Save. DPMS sends the access configuration to the backend.

From this point, only the users or groups you specified (plus anyone with overall administrative rights) will see this incident in their index. This is a record-level restriction — it does not change anyone's global DPMS role, but it adds an additional layer of control on top of module-level permissions.

Updating the status quickly without opening the Edit form

If you just need to change the status — for instance, to mark an incident as "Under Review" while the workflow is running — you don't need to open the Edit form at all. On the Detail screen, the sticky header at the top of the page shows the current status in a dropdown. Changing the value there saves immediately without a separate Save button click. The same applies to the responsible persons field in the sticky header.

Field reference

Name — The incident's title. Required. Supports multilingual input. Shown in search results and the index list.
Responsible person(s) — One or more DPMS users assigned as accountable. Controls who can edit the record if their rights are "edit only assigned". Can be left empty initially.
Status — The incident's current lifecycle stage (e.g. Processing, Review, Resolved). Defaults to Processing for new incidents. Setting this to Resolved locks all linked tables. Custom statuses configured by your organisation also appear here.
Incident Date — Date and time when the incident actually occurred. Optional at creation, but required for complete regulatory reporting. Stored as a precise timestamp.
Reporting Date — Date and time when the incident was formally reported. Defaults to the current moment when creating a new incident. Adjust if reporting happened at a different time.
Description — Free-text narrative of what happened, scope of data affected, how it was discovered, and initial response actions. Supports multilingual input and AI-assisted translation.

Log entry fields (Log tab):

Name — Short title for this log entry, e.g. "DPA notified". Required.
Date — When the logged event happened. Defaults to now for new entries.
Description — Detailed narrative of the specific event or action. Required for a useful audit trail.

How this connects to the rest of DPMS

The incident record you edit here is the anchor point for multiple other DPMS modules:

Tasks module: Tasks linked on the Tasks tab appear in the DPMS task index and in the responsible person's task dashboard. Progress on those tasks is visible from both the task and incident sides.
Assessments module: Linked DPIAs and compliance assessments show the incident as a related item, making it easy for assessors to understand the broader risk context.
Documents module: Linked policies and procedures appear as "associated incidents" in the document detail view.
Workflow engine: Workflows triggered via the Trigger Workflow tab create required-action items in the workflow dashboard and send notifications to reviewers. The incident cannot be edited by other users while certain workflow states are active.
Activity log: Every change to the incident — who changed what field and when — is captured automatically. Click the clock icon in the top-right of the Detail screen to open the full activity log. This is your primary evidence for demonstrating to auditors that the record was properly maintained.

After completing your edits, use the Back/Cancel link to return to the Detail screen and review how the incident looks in its read-optimised view. From the Detail screen, you can also share the incident (if sharing is enabled by your IT administrator) via the three-dot options menu.

Tips & common pitfalls

Heads up: Setting an incident's status to "Resolved" immediately locks all linked tables — Tasks, Documents, Assessments, and Log entries all become read-only. If you need to add a final log entry or link a last document, do it before changing the status to Resolved. To unlock a resolved incident, you must change the status back to another value (if your permissions allow it).

Tip: The Reporting Date defaults to "now" when you create a new incident, which is usually correct — you are logging it as you discover it. However, the Incident Date is left blank and must be filled in manually. Don't forget to go back and enter the actual occurrence date once you know it; incomplete records may cause issues with regulatory deadline calculations.

Status changes on the Detail screen save immediately. The sticky header status dropdown on the Detail screen does not have a Save button — changing the value saves instantly via a background request. This is different from the Edit form, where all changes wait for you to click Save. If you change the status in the Detail view and then open the Edit form, the form will already reflect the new status.
"Edit only assigned" users lose access if removed as responsible person. If a colleague has "edit only assigned" rights and another user with full permissions removes them from the Responsible Persons list, that colleague will no longer be able to open the Edit form for that incident — they will see an access denied page on their next visit. Plan responsible person changes carefully.
The Manage Access tab controls record-level visibility, not global roles. Restricting access here does not change a user's overall DPMS permissions. It adds a filter on top: a user who has general incident read rights but is not in the access list for this specific record will not see it in their index.
Automatic translation requires AI to be configured. The Name and Description fields both show a translate button. If your organisation has not yet configured AI translation settings in IT Settings, clicking the button will not produce a translation. Check with your IT administrator if translation is not working.
Log entries are permanent and chronological. Once saved, log entries cannot be edited or deleted through the UI. The audit trail is intentionally immutable. If you make a mistake in a log entry, the correct approach is to add a new entry that clarifies or corrects the earlier one.