Incidents
Log, triage and close out incidents — plus notifications and the public reporting form.
11 min read9 sectionsAll roles (some actions owners and admins only)
The Breach & Incident Register records what went wrong, why, and what you did about it — including notifiable breaches and everyone you told. Use it to log incidents, track them to closure, and review reports that arrive through your public reporting form.
Open Incidents in the sidebar to see every incident you have access to.
The page is headed Breach & Incident Register. You can search titles (Search incidents…), narrow to an organisational unit, and filter by severity or by breach — All incidents, Notifiable breaches or Breaches pending notification. Export CSV downloads the rows shown.
Register columns
- Incident ID
The register key, such as
INC-101. It stays pinned when you scroll sideways.- Incident Title / Incident Description
What happened.
- Severity / Status
Severity uses your organisation's labels. See Severity, status and root cause.
- Owner
The person handling the incident.
- Classification
Public, Confidential, or Highly sensitive for an incident restricted to named people.
- Privilege
Marks a privileged incident; a dash means non-privileged.
- Shared
Other units the incident is also visible to.
- Breach
Breach · pending or Breach · notified for a notifiable breach.
- Occurred
When the incident happened.
- Treatment Plans Overdue
Yes when a linked treatment plan you can see is overdue.
Each row has View, which opens the incident's page, and Propose Update, which opens the edit form.
Every new incident starts as a proposal that an owner or admin approves.
- 1
Click New in the top bar
It is on every page.
- 2
Choose Incident
Pick it from the record types at the top of the form. The heading changes to Create New Incident.
- 3
Fill in the details
See Incident fields. The AI Assistant panel can draft content — Fill Form copies it in and marks each field AI filled. Check those fields before submitting.
- 4
Click Submit (propose), then Submit to Queue
You are taken to the new proposal.
- 5
Wait for approval
An owner or admin reviews it in Proposals. The incident appears in the register once approved.
The form's fields, in the order they appear.
- Title
A short name for what happened.
- Organisational Unit
The part of your organisation the incident belongs to.
- Also visible to
Other units that can view and link to it. Only owners and admins can set it; members see the field greyed out.
- Proposed Severityrequired
Defaults to Medium.
- Severity Justification
Why you chose that severity. Reviewers read it.
- Proposed Statusrequired
Defaults to Open.
- Status Justification
Context for the status, such as investigation progress.
- Description
What happened.
- Occurred Atrequired
When it happened.
- Detected At
When it was discovered. Blank means the occurred time.
- Resolved At
Available when the status is Resolved or Closed.
- Owner (Responsible Party)
Who is handling it.
- Incident Category
Primary and optional secondary category.
- Is This a Systematic Issue?
Yes, No or I don't know.
- Root Cause and Control Failure
- Remediation / Lessons Learned / Impact Description
What was done, what you learned, and the business impact.
- Notifiable breach
See Notifiable breaches.
- Affected Systems / Notified Parties
Free-text notes. Record who was actually told in the notification register.
- Next Review Date
When to look at it again.
- Classification / Privilege
See Restricting access.
- Linked Controls, Risks, Obligations, Evidence, Treatment Plans, Policies
Existing records to link, applied on approval.
- Additional Information (optional)
Notes for the reviewer.
How bad the incident is, how far along it is, and why it happened.
Severity (default labels)
- Low
Lowest.
- Medium
The default.
- High
Second-highest.
- Critical
Highest for an incident.
Owners and admins can rename these under Settings → Severity Labels. Incidents always use four levels, even if your risk scale has five.
Status
- Open
The default for a new incident.
- Investigating
Under investigation.
- Resolved
The issue has been remediated.
- Pending Closure
Waiting to be closed.
- Closed
All documentation is complete.
Root cause is how it happened — say, a phishing email. Choose a Root Cause Category, then add Root Cause Details.
Control failure is why it wasn't prevented — say, multi-factor authentication not deployed. Choose one or more categories from your control taxonomy, then add Control Failure Details.
Flag breaches that must be reported, and keep an auditable record of everyone you told.
Tick Notifiable breach on the form, then fill in Regulator notified and Date notified — leave the date blank until you've notified. The register shows Breach · pending until a date is recorded, and the Breaches pending notification filter lists every such incident.
Each incident's page has a Notification Register, one row per party told. Owners and admins click Record notification; anyone who can see the incident can read it. Export CSV appears once at least one notification is recorded. Entries save directly, not as proposals.
Record a notification
- Party notifiedrequired
Who you told.
- Party typerequired
See the list below.
- Method
Regulator portal, Email, Phone, Letter, Public notice or Media statement.
- Date notified
Leave empty for a notification not yet sent.
- Deadline
When it is due.
- Notified by / Reference number
Who sent it, and any receipt number from the recipient.
- Reason for delay / Notes
Explain a late notification; anything else.
Party types
- Regulator
External
- Affected individuals
External
- Customer
External
- Insurer
External
- Board
Internal
- Law enforcement
External
- Vendor/Processor
External
- Partner
External
- Media
External
- Internal team
Internal
Notification status
- Notified
A date notified is recorded.
- Pending
Not sent, and the deadline hasn't passed.
- Overdue
Not sent, and the deadline has passed.
Classification and privilege decide who can see an incident at all.
- Public
Visible to everyone who can see its organisational unit.
- Confidential
Only people who hold Confidential access.
- Highly sensitive
Only the people named under Restricted to. For a very small number of incidents.
- Privileged
A separate setting: only people who hold Privileged access.
Highly sensitive opens a Restricted to picker, which offers only people who hold Confidential or Privileged access. You are pre-selected so you keep seeing it; untick yourself only if someone else will own it. No role, grant or sharing widens access beyond the list. These incidents are left out of the dashboard, the weekly digest and the AI assistant. Reports count them and list them as Highly sensitive, with no title, description or detail — for the people on the list as well.
An incident shared into your unit is read-only to you; Make your own opens a pre-filled create form for your own copy (not offered for Highly sensitive incidents). Access levels are granted per person — see the Settings guide.
Let staff, suppliers or the public report an incident without a ShelfGRC account.
Where links live
Owners and public report handlers manage them on the Public Reports tab here, or under Incident Reporting in Settings.
What reporters fill in
Incident Title, Description, Severity and When did it occur?. Other details, including their name and email, are optional.
What happens next
The reporter gets a reference such as INC-RPT-2026-0001. The report waits for review — it isn't an incident yet.
- 1
Click New Link under Incident Reporting Links
- 2
Add a Public heading (optional)
Anyone with the link can read it — keep confidential detail out.
- 3
Set Expiry date and Max submissions (optional)
A blank expiry defaults to 12 months from today. A blank cap means unlimited.
- 4
Click Create & Copy Link
The URL is copied and shown in the table.
Links show Active, Expired or Disabled, with a submission count. Row buttons copy, open, edit, disable or delete a link; editing never changes its URL. Get new URL replaces a link's URL — the old one stops working, so share the new one. A link whose expiry you clear shows Never and keeps accepting reports until disabled.
Owners, and the people they choose to handle public reports, decide which submitted reports become incidents.
Owners always get an email and a notification in the bell for each new report, and can review the queue. An owner can add anyone else by ticking Handles public incident reports when inviting them — during setup or in Settings → Organization Management — or later in Change Role & Access. Role makes no difference: an admin handles public reports only if the box is ticked for them. Settings → Incident Reporting lists everyone who handles reports under Who handles public reports.
- 1
Open Public Incident Reports
It starts on Pending review; other filters include Converted to proposal and Rejected.
- 2
Click the eye icon to read a report
- 3
Accept or reject it
Accept opens the new-incident form filled in from the report. Nothing is saved yet — cancel and the report stays pending. Reject takes an optional Rejection reason.
- 4
Set it up, then accept
Choose the Owner (required), the Business Unit and who else it is visible to, and its security settings — Classification, Legal privilege or Highly sensitive — then click Accept and send to owner. The owner must be able to see that business unit and the security settings you chose. Nothing is created yet: the new incident is sent to its owner in Proposals, and they get an email and a notification in the bell.
- 5
The owner approves it
The owner approves or rejects it in Proposals, where it shows Assigned to you — even if they cannot otherwise approve proposals. Once approved it joins the register as Open. Whoever accepted the report cannot approve it for the owner, but an owner who did not accept it, or an admin whose units include the incident's business unit, can step in. If you chose yourself as the owner, you approve it yourself, unless your organisation requires a second approver.
- 6
If it is rejected
The report goes back to Pending review, so it can be accepted again and sent to someone else.
Remove an incident for good, or take its data elsewhere.
Owners and admins see Delete on an incident's page. Delete permanently removes it immediately with its links, history and notification records — including the names and contact details of everyone notified. It is not a proposal and cannot be undone.
Register CSV
The filtered rows, including root cause, control failure and linked records.
Standard reports
Incident Summary and Trends Report and Incidents Register Report. See the Reporting guide.