Incidents
Incidents
Introduction
The Incidents module in CERRIX helps organisations register, investigate, and follow up on incidents to prevent recurrence and implement improvement actions.
Purpose of the Incidents Module
Incidents are unplanned events that impact or could impact your organisation. The Incidents module provides a structured way to:
Record incidents including cause, impact, and status
Assign tasks and responsibilities
Add evidence and supporting documents
Link improvement measures (MoIs) to incidents
Report on trends, volumes, and resolution times
Benefits for Users
One central location for all incident reports
Clear workflow from registration to closure
Visibility into open and resolved incidents
Automatic task assignment and notifications
Complete audit trail for regulatory reporting
Important: Incidents in CERRIX can only be created via Forms, not directly in the Incidents workspace. Forms provide a consistent intake process and ensure all required information is captured from reporters.
Roles in Incidents
Your role determines what you can do within the incident management process. Every incident has defined roles and an automatic workflow that ensures clear responsibilities and follow-up.
Reporter
The Reporter initiates the incident registration. They:
Describe what happened, when, and what the impact was
Add documents or evidence files
Submit the incident via a Form
Transfer ownership to the Responsible party
Reporters are often the people who witnessed or discovered the incident, not necessarily those who will investigate it.
Responsible (Owner)
The Responsible party is accountable for investigation and resolution. They:
Analyse the root cause
Assess severity and impact
Assign a Delegate for specific tasks (if needed)
Update the incident status (e.g., Under investigation, In progress)
Process findings and mark the incident as "Ready for review"
The Responsible party drives the incident to closure and ensures all necessary actions are completed.
Delegate
The Delegate works on assigned investigation or remediation tasks. They can:
Contribute to the investigation
Add progress updates and comments
Upload supporting documents
However, Delegates cannot change the final incident status – that remains with the Responsible party.
Reviewer / Auditor
The Reviewer validates that the incident was properly investigated and resolved. They:
Check quality of documented information and evidence
Verify that root causes were identified and addressed
Formally close the incident with "Closed" status
The Reviewer provides quality assurance and ensures incidents are genuinely resolved, not just marked as complete.
Workflow Summary
Reporter submits incident → Responsible investigates and resolves → Delegate assists with execution → Reviewer validates and closes
This workflow creates accountability at each stage and prevents incidents from being forgotten or inadequately addressed.
Incidents Workspace
The Incidents workspace is your central overview of all incident reports in your organisation. You can view, filter, and follow up on incidents from this location.
What You See in the Workspace
The workspace displays a list of all incidents you have access to. Each row shows:
Incident type – Category (e.g., operational, IT, data breach, security)
Status – Current stage (Reported, In progress, Closed)
Priority – Urgency (Low, Medium, High, Critical)
Responsible – Who owns the investigation and resolution
Incident date – When the incident occurred
Due date – Deadline for resolution
Colour coding or symbols help you quickly identify incidents that need attention.
Workspace Functions
Advanced configuration opens expanded filter options. You can filter by:
Status (e.g., show only open incidents)
Priority (e.g., High and Critical only)
Department or business unit
Responsible party
Date ranges
Table configuration lets you control which columns are visible. This helps you focus on information relevant to your role or current task.
Preset management saves your filter and column configurations:
Click + to save a new preset with a descriptive name
Click ***** to set a default preset that loads automatically when you open the workspace
Click X to delete unwanted presets
Practical Example
You want to see only incidents that are still "In progress" for your department:
Set a filter: Status = In progress AND Business dimension = your department
Save this as a preset called "My Active Incidents"
Set it as your default preset
Now this view loads automatically every time you access the Incidents workspace.
Opening Incident Details
Click on an incident name to view complete details, including:
Full description and timeline
Root cause analysis
Linked risks and controls
Attached documents and evidence
Status history and comments
Linked MoIs (improvement measures)
Registering an Incident
As mentioned earlier, incidents are created via Forms, not directly in the Incidents workspace. However, once you have access to create incidents through a Form, the process works as follows:
Core Information
The incident Form will guide you through providing:
Incident name – A clear, concise title that describes the event (e.g., "Unauthorised access to customer database" or "Payroll data processing error")
Incident type – Select the appropriate category:
Data breach or privacy incident
Operational failure
IT system outage
Security incident
Compliance violation
Other (specify)
Incident date – The date when the incident occurred, not when it was discovered or reported
Organisation / Business dimensions – Link to the affected department, process, or location
Incident Details
Provide complete information about what happened:
Description – Explain the incident clearly:
What event occurred?
When was it discovered?
What systems or processes were affected?
Who was impacted (customers, employees, partners)?
Cause – What led to this incident?
Human error?
System failure?
External attack?
Process gap?
Understanding the root cause is essential for prevention.
Impact – Describe the consequences:
Financial losses
Data compromise
Service interruption
Reputational damage
Regulatory exposure
Be specific. "Minor impact" is vague; "45 customer records exposed" is clear and actionable.
Role Assignment
Assign the parties who will manage the incident:
Responsible – Who will lead the investigation and resolution
Delegate (optional) – Who will assist with specific tasks
Choose people with appropriate knowledge and authority to address the incident effectively.
Submission
Click Save or Submit (depending on your Form configuration) to register the incident. The incident enters the workflow, and the Responsible party receives a task notification to begin investigation.
Incident Workflow
Every incident follows a standard workflow from registration to closure. This structure ensures consistency, clear ownership, and complete traceability.
1. Reported / Registered
The incident has been submitted by the Reporter via a Form. At this stage:
Basic information is captured
The Responsible party receives an automatic task notification
Investigation can begin
Key focus: Ensure the description clearly explains what happened, when, and what the initial impact appears to be.
2. Under Investigation
The Responsible party or Delegate investigates the root cause. During this phase:
Analyse what went wrong and why
Collect evidence and supporting documentation
Interview relevant parties if needed
Document findings in the Details and Comments tabs
Upload investigation documents via the Documents section
Thorough investigation is critical. Superficial analysis leads to recurrence.
3. In Progress
Corrective actions are being executed. This might include:
Fixing technical issues
Updating procedures
Providing additional training
Implementing control improvements
A Measure of Improvement (MoI) can be linked to the incident if systemic changes are needed. The MoI tracks these improvements separately while remaining connected to the incident.
Update the incident status regularly to show progress and maintain stakeholder confidence.
4. Ready for Review
The Responsible party marks the incident as complete and ready for validation. This signals:
All investigation is finished
Root causes are documented
Corrective actions are implemented
Evidence is uploaded
The incident is ready for quality review
The Reviewer or Auditor receives an automatic task notification to assess the incident.
5. Closed
The Reviewer confirms the incident was properly handled:
Investigation was thorough
Root causes were correctly identified
Corrective actions are appropriate and implemented
Documentation is complete
Upon approval, the status changes to "Closed". The complete history remains accessible via the History tab for audit and compliance purposes.
If the Reviewer finds issues, they can reject closure and return the incident to "In progress" with specific feedback about what needs correction.
Linking MoIs to Incidents
Not every incident requires a formal improvement measure, but many do – especially those revealing systemic issues or control gaps.
When to Create an MoI
Consider creating an MoI when:
The incident reveals a process weakness
Controls need strengthening
Training is required
Policies need updating
Technology improvements are needed
MoIs turn reactive incident response into proactive improvement.
How to Link an MoI
Open the incident
Navigate to the Event MoI tab
Click Add MoI
Complete the MoI details (see Measures of Improvement training)
Click Save MoI
The MoI is now linked to the incident. Progress on the improvement is tracked separately, but the connection ensures you can trace improvements back to their triggering incidents.
Why Link MoIs?
Linking creates traceability and demonstrates organisational learning. During audits or management reviews, you can show:
What incidents occurred
What root causes were identified
What improvements were implemented
Whether similar incidents decreased after improvements
This closed-loop approach transforms incident management from reactive firefighting into systematic risk reduction.
Best Practices
Report Incidents Promptly
Quick reporting enables faster response and reduces impact. Encourage a culture where incidents are reported immediately without fear of blame. The goal is learning and improvement, not punishment.
Be Thorough in Descriptions
Clear, complete descriptions eliminate confusion. Include:
Timeline of events
Systems or processes affected
Initial observations
Immediate actions taken
Good documentation at the start saves time during investigation.
Focus on Root Cause, Not Blame
Incident investigation should identify systemic causes, not scapegoats. Ask "why did this happen?" repeatedly until you reach underlying factors:
Why did the error occur? → Process was unclear
Why was the process unclear? → Documentation was outdated
Why was documentation outdated? → No review schedule exists
Root cause: Lack of process ownership and review cycle
Address root causes to prevent recurrence.
Link Related Incidents
If you see patterns across multiple incidents, document those connections. Linked incidents reveal trends that might not be apparent when viewing individual cases.
Update Status Regularly
Don't let incidents sit in "Under investigation" for weeks without updates. Regular status changes maintain visibility and demonstrate progress. If investigation is stalled, document why and escalate if needed.
Close Incidents When Genuinely Resolved
Premature closure hides ongoing problems. Late closure makes reporting inaccurate. Close incidents when:
Root cause is confirmed
Corrective actions are completed
Evidence is documented
Review is passed
Exercises
Exercise 1: Register a New Incident
Use the appropriate Form to create a new incident in the training environment
Complete all fields: name, type, description, cause, impact, responsible party, and due date
Submit the incident
Exercise 2: Progress Through the Workflow
Update your incident from "Reported" to "Under investigation"
Add a document as investigation evidence
Change status to "In progress" and add a progress comment
Mark as "Ready for review"
As a Reviewer (or with your trainer), close the incident
Exercise 3: Link an MoI
Create or identify an incident that requires systematic improvement
Add a linked MoI describing the improvement action needed
Verify the link appears in both the Incidents workspace and MoI workspace
Track both the incident closure and MoI completion separately
Last updated