Author: Naeem Sarfraz

Version: 6.0

Last update / review: 4 May 2026

INCIDENT COMMUNICATION AND REMEDY

Litigationware Limited t/a FinLegal — Incident communication and remedy.

1. VERSION HISTORY

2. OVERVIEW

This document defines FinLegal's Service Level Agreement (SLA) and the approach we take to communication and remedy of Customer-affecting service issues.

We use the term incident to mean any disruption or defect on the FinLegal platform that affects, or has the potential to affect, the Customer's operations.

Service issues that arise from the Customer's own actions — for example, case configuration choices, data quality during import, or requests for new functionality — fall outside this SLA. They will continue to be addressed promptly, but are not subject to the timings in section 4.

This SLA does not include service credits. Where service credits apply, they are governed by the Customer's commercial agreement with FinLegal and not by this document.

3. SEVERITY CLASSIFICATION

Severity is determined by two factors:

• Scope — how many users and which clients are affected.

• Impact — how seriously each affected user is impacted, including whether data integrity or security is at risk.

The combination of the two produces an overall severity, mapped to one of four priority levels.

A core feature is a capability whose failure justifies an immediate response, including out of UK working hours. The current list is reviewed periodically and is available on request.

Where a workaround is identified that materially mitigates the impact, the priority will be downgraded accordingly. The Customer will be notified when a downgrade is applied.

4. SERVICE LEVEL AGREEMENT

The SLA covers four commitments at each severity: how quickly the Customer is notified, how quickly investigation begins, how often updates are provided, and the target for restoration of service.

FinLegal distinguishes between mitigation (service restored, or a workaround in place that allows the Customer's operations to continue) and permanent resolution (the root cause has been removed and a fix released). For Critical and High incidents, the targets below refer to mitigation; permanent resolution follows on a timeline appropriate to the underlying cause and is communicated through the incident report.

P1 notifications are posted to the FinLegal status page (https://status.casefunnel.io/) and emailed to the Customer's named contact. P2 to P4 notifications are issued by email from the Customer's implementation manager.

For P3 and P4, the timings above apply where the Customer raised the report — in which case the notification confirms receipt and the resulting assessment — or where an internally-found issue affects Customer operations. Low-impact issues found internally that have no Customer-facing effect are addressed in the next planned release without a separate notification.

UK working hours are 09:00 to 17:00 Monday to Friday, excluding UK public holidays.

P1 incidents are responded to in the same way regardless of the time of day or the time zone of the Customer. P2 to P4 timings are expressed in working hours, working days and working weeks, as the underlying work is performed within UK working hours.

Targets above are FinLegal's commitment in the typical case. Where the root cause of an incident is unusually complex, or where remediation is dependent on an external party (a third-party supplier, a cloud provider, or a pending change on the Customer side), a stated target may be exceeded. In such cases FinLegal will inform the Customer before the target is exceeded, communicate a revised target, and continue updates at the agreed cadence.

5. SUPPORT CHANNELS

When calling the ROW helpdesk for a Critical (P1) issue, the line goes straight to voicemail. Leave your name, a contact number, and a short description of the issue. Follow up by email to helpdesk@finlegal.io with as much supporting information as you can — please do not include personally identifiable information (PII).

6. INCIDENT NOTIFICATION — CRITICAL (P1)

Critical incidents are identified in two ways.

Automatically. FinLegal's monitoring detects infrastructure and core-service issues and pages the on-call engineer directly.

By the Customer. Where a critical issue is identified by the Customer rather than by FinLegal monitoring, the Customer should escalate via the ROW helpdesk. The on-call engineer is paged on receipt of the voicemail, with up to three call attempts made before the alert escalates to the FinLegal management team.

FinLegal's on-call engineers are equipped and available to respond within thirty minutes of being paged. Acknowledgement of the page is the trigger for the 15-minute notification commitment to the Customer.

Once the page has been acknowledged, the on-call engineer will:

• Triage the incident, including assessing whether a recent platform release is a contributing factor and whether a rollback is appropriate.

• Engage the Customer's named FinLegal contact to coordinate communication on the Customer side.

• Escalate to senior FinLegal management where the impact warrants additional resource or direction.

• Discuss and agree remedial steps with the Customer where the change has a material effect on the Customer's data or running operations.

7. INCIDENT RESPONSE AND UPDATES — CRITICAL

Active investigation continues 24/7 until the incident is resolved or downgraded. Updates are communicated hourly through:

• The FinLegal status page (https://status.casefunnel.io), to which the Customer's wider team can subscribe for direct notification.

• Email to the Customer's named contact.

Once the addressable symptoms have been remedied, any longer-term follow-up work — for example, data reconciliation, hardening, or replacing a hotfix with a permanent fix — reverts to the response and update cadence in section 9, within UK working hours.

8. INCIDENT NOTIFICATION — NON-CRITICAL (P2 TO P4)

Non-critical incidents may be raised in any of the following ways:

• By a member of the Customer's team to their FinLegal delivery contact, or to helpdesk@finlegal.io.

• By a FinLegal team member who has discovered an issue while working with the Customer.

• By FinLegal application monitoring; where the issue has Customer-affecting impact, FinLegal will notify the Customer.

Each non-critical incident is triaged by FinLegal's technical team, who confirm scope and impact and assess priority. Where triage indicates P1 or high P2, the assessment is escalated within FinLegal management. The Customer's implementation manager is the customer-facing point of contact and communicates the assessment, planned remediation and progress updates to the Customer. FinLegal assumes the worst case when assigning impact and only downgrades when the actual scope and impact are understood.

If, on review, the report is determined to be a change request or feature request rather than an incident, it is closed and added to the change and feature backlog. Disputes about classification are escalated for agreement between senior team members on the Customer side and at FinLegal.

9. INCIDENT RESPONSE AND UPDATES — NON-CRITICAL

For P3 and P4 incidents, the implementation manager ensures that the supporting record is updated monthly, or on request, by the team members working on remediation. Where multiple P3 or P4 items are open with the same Customer, the monthly update may be issued as a single batched digest covering all of them. Each update will include:

• The cause, where known, and the presently understood impact.

• The likely time to remedy based on current information.

• Any impact that is unlikely to be remedied (for example, by design or by deliberate prioritisation).

For P1 and P2 incidents:

• A plan for remedy and communication is defined and tracked.

• The implementation manager agrees with the Customer who needs to be communicated to — the wider Customer team, the Customer's clients, regulators where applicable — and the timing and method of those communications.

• Written updates are provided to the Customer (verbal updates available on request), and will include:

◦ The cause, where known, and the presently understood impact.

◦ The likely time to remedy.

◦ Any impact that may not be remediable.

◦ Proposed reputational and regulatory communications, including any that fulfil legal requirements such as GDPR breach notification. These are agreed with the Customer before being issued.

◦ Actions completed and pending.

• Updates continue until the incident is jointly agreed as concluded.

• Where calls or video conferences are used, they are chaired by the implementation manager unless a more senior member of the FinLegal team has assumed ownership of the response.

10. INCIDENT REPORTING

For every P1 incident, and for P2 incidents at the Customer's request, FinLegal will produce a written incident report. The report is sent to the Customer's named contact by the implementation manager and includes:

• A summary of the incident.

• How the incident occurred.

• A timeline.

• The events leading up to the incident.

• Steps taken by FinLegal during the incident.

• Steps that will be taken by FinLegal following the incident, including any preventative work, monitoring or regression coverage.

• Recommended steps for the Customer.

P1 incident reports are produced within 24 hours of resolution. Where the incident remains open beyond 24 hours, an interim report is shared and the final report is issued at resolution.