Incidents and concerns

Audience: ISMS Admin.

The two routes in: an administrator logs an incident directly, or a member of staff reports a concern from your SharePoint site and Certaria brings it into the register. Both end in the same place.

How staff report something

Your people use the Report a concern route on your ISMS site. They add their own entry and can see only their own, which is the point: someone reporting a concern about a colleague should not find it readable by that colleague.

Certaria syncs concerns into the incident register on a schedule. A concern is a report, not yet a finding, and triage is yours.

Lower the barrier and you will hear about more

If you enabled the daily incident prompt during onboarding, everyone gets a low friction ask in Teams about whether there is anything to report. The value is not the prompt itself; it is that people who would never open a form will answer a message.

What happens automatically at High severity

High and above alerts immediately, and it cannot be batched

The moment an incident is saved at High severity or above, Certaria sends both an email and a Teams message so it is never left sitting in a queue. This fires on save, not on a schedule.

Every alert is recorded under System Health, so you have an audit trail of who was told and when. An auditor asking “how do you know your escalation works?” is asking for exactly this.

Below High severity, nothing is sent. That is deliberate: an alert that fires for everything is an alert nobody reads.

The review stage opens a corrective action

When an incident reaches its Review stage, Certaria opens a corrective action against it automatically, so the lesson is captured rather than lost when the incident is closed.

Three things worth knowing:

• It checks first whether one already exists, so moving back and forth through the stages will not create duplicates.
• The new item appears under Corrective Actions.
• It records the action quietly and sends no notification, because you are already looking at the incident when it happens.

Closing an incident without a corrective action is the failure mode this prevents. ISO 27001 asks what you learned, not just what happened.

Corrective actions are chased like anything else

Once open, a corrective action has an owner and a due date, and it is picked up by the same reminders as compliance tasks: a daily message to its owner when overdue, and a warning as the due date approaches. See Tasks and deadlines.

What an auditor asks about incidents

• Can you show the report reached the right person? The System Health record of alerts.
• What did you change as a result? The corrective action, and whether it closed.
• How does someone raise a concern? The route on your site, and that it is available to everyone.
• Have you had none at all? An empty incident register is not automatically good news, and an auditor may read it as nobody knowing how to report. The daily prompt is part of the answer.

Common failure modes

Symptom	Cause	Fix
A serious incident sent no alert	It was saved below High severity	Severity drives the alert. Reclassify and save
Concerns are not appearing in the register	The sync is scheduled, not instant, or the site URL in configuration is wrong	Wait for the next run, then check the configuration record
Duplicate corrective actions on one incident	Should not happen: the check prevents it	If it did, close the surplus and report it
An incident closed with nothing learned	It never reached the Review stage, so no corrective action opened	Move it through Review rather than straight to Closed
Staff say they cannot find where to report	The site navigation was not provisioned, or they are looking in the app	Concerns are reported on the SharePoint site, not in the model-driven app

Next

• Tasks and deadlines, which chase corrective actions
• Who can see and do what, which governs who can read a concern
• What your people see in Teams