Purpose

To provide a standardised approach for addressing non-emergency incidents across systems, tools, or workflows that may degrade service or productivity but do not result in critical failure or safety risks. The goal is to resolve issues efficiently while preserving audit trails and promoting continuous improvement.

Scope

This procedure applies to all internal non-emergency incidents reported by employees, including:

• Software bugs or glitches
• System performance issues
• Access problems or user errors
• Internal policy violations (non-critical)
• Workflow breakdowns (e.g. approvals not routing)

Roles & Responsibilities

• Incident Reporter (Employee)
• Identifies the issue and submits a ticket or report with details.
• Incident Manager (IT or Ops Lead)
• Coordinates the response process, assigns tasks, and ensures timely resolution.
• Resolver (IT Engineer, Admin, or Functional Owner)
• Investigates the incident, applies the fix, and documents resolution steps.
• Reviewer (Team Lead or Compliance Officer)
• Conducts a post-resolution review to assess process quality and identify improvements.

Process Steps

1. Incident Identification & Reporting

Any employee who encounters a system anomaly, process issue, or unexpected outcome must submit a report via the internal incident ticketing system or designated form.

The report should include:

• A clear summary of the issue
• Steps to reproduce (if applicable)
• Impact scope (who/what was affected)
• Screenshots or logs (optional)

All reports are timestamped and assigned a unique incident ID for tracking.

2. Initial Triage & Classification

The Incident Manager reviews the ticket within 4 business hours and classifies the incident based on:

• Severity (Low, Medium, High)
• Impact (User-specific, team-wide, org-wide)
• Category (System bug, user error, process failure, configuration issue)

Based on classification, the ticket is assigned a resolution priority. If the incident is misclassified as non-emergency but found to be urgent, it is escalated immediately to the Emergency Protocol.

3. Assignment to Resolver

The ticket is assigned to the most appropriate resolver (e.g., IT support for login failures, HR Ops for workflow issues). The resolver acknowledges receipt and starts investigation within 1 business day.

Communication is kept open with the reporter via ticket updates or internal chat.

If additional context or data is needed, the resolver requests it promptly to avoid delays.

4. Investigation & Resolution

The resolver performs diagnostics, testing, or internal data queries to identify root cause. For technical issues, logs and monitoring tools may be used; for process issues, stakeholder interviews may be necessary.

Resolution actions may include:

• Software patch or config fix
• Process re-alignment or clarification
• Manual override or re-processing
• Training reminder or documentation update

All actions are recorded in the ticket notes with timestamps, and system changes are logged per IT policy.

5. Verification & Closure

Once the issue is resolved, the original reporter (or affected team) is asked to verify that the solution is satisfactory. After confirmation, the ticket is marked as Resolved and transitioned to Closed after 48 hours of no further issues.

Before closing, the Incident Manager verifies that:

• All required fields are completed
• All steps are logged clearly
• Supporting documentation is attached (if applicable)

6. Post-Incident Review (Optional)

If the incident is rated as High Severity, or recurs multiple times, a short post-incident review is conducted within 5 days. The review involves:

• Summary of incident and timeline
• Root cause analysis (RCA)
• Preventive measures taken
• Recommendations for SOP or policy updates

The review is documented in a shared team space or logged in an internal tracking dashboard.

Documentation & Tools

• Incident ticketing system (e.g., Jira, ServiceNow)
• Incident submission form (template)
• Root cause analysis template
• Knowledge base for known issues
• System logs and monitoring tools

Compliance & Recordkeeping Requirements

• All incidents must be logged in the ticketing system
• Resolution notes must be complete and timestamped
• System changes must follow change control protocol
• Incidents with user data or compliance implications must be flagged for review
• Retain incident records for 12 months minimum