Customer Service Level Agreement

1. Introduction #

The Interu platform is designed to be robust and easy to use, ensuring that it is reliable and easy to support. As part of its commitment to ensuring the best possible experience, iov42 maintains a comprehensive set of SLAs (Service Level Agreements). These agreements ensure that users of the Interu production platform are aware of what levels of support exist, how to access them, and when they are available. The Interu UAT platform is not covered by this SLA but will be operated on a best effort basis.

Duties #

iov42 will offer support following industry best practice. As set out in this document, iov42 will maintain support channels and processes to ensure Interu performs to the expectations defined in this document.

Customers are under a duty to ensure that the software and hardware used to access Interu meet the minimum requirements as set out in the FAQ on the Interu help site. They are also obliged to familiarise themselves with the platform prior to raising support requests.

2. Definitions #

“Business hours” are 08:00 to 18:00 Monday to Friday (UK time).

“Development tasks” Are tasks or units of work that are undertaken by the software engineering teams.

“Incident” An Incident is defined as an unplanned interruption or reduction in quality of the service.

“Problem” a Problem is a cause, or potential cause, of one or more incidents and may be raised as a response to an incident.

“Support tasks” Are tasks or units of work undertaken by the 1st level support team.

Definition of times #

Start of Incident
Incidents are triggered by the following events:

1. The Incident ticket being created on the Incident Management System, as stated on the Incident ticket; or
2. The start of the Incident (based on the time of first alert).

From the time of the Incident being triggered duration will be measured in minutes.

Incident resolution
Incidents are considered resolved when either of the following is true:

1. The affected service is returned to expected functionality or performance.
2. A suitable work around is communicated to the user base.
3. A low priority Incident is closed and a Problem is raised.

Start of Problem
A Problem is created when an Incident is caused, or thought to be caused, by an underlying issue with the software platform. This can be triggered by the following events:

1. An Incident is both low priority and low impact and is caused by issues that require a development task to resolve.
2. An Incident has been triaged into a low priority and no longer requires an immediate fix.

End of Problem
A Problem is resolved with either of the following:

1. A fix is developed and pushed into production, returning functionality or performance to expected levels.
2. The Problem is marked as no longer required to be fixed, either because investigation cannot ascertain the root cause, or the problem is no longer relevant.

Priority level definitions #

As Interu and its related services are a SaaS (Software as a service), priorities are set against the whole of the user base and not individual organisations. For instance, a P0 is only triggered when the majority of the Interu users are unable to access the platform:

P0: A complete outage of service that affects the majority of the user base.

P1: A major component of the software is degraded or unavailable affecting the user’s ability to continue operations. For instance, some of the platform is working, but not enough to allow licensees to perform operations. Examples: i) Interu’s integration with TRACES NT not working (which could be an issue with Interu and / or TRACES NT); ii) an interruption importing purchase orders from the licensee’s own internal ERP or WMS.

P2: A degradation of features or platform that impedes the user’s efficient use of the platform for the majority of the user base. Most of the platform is working but one or more features are not usable and licensees can continue to operate. For example, bulk adding information or viewing records with a filter applied is not working.

P3: A degradation or outage of non critical features that allow the user’s continued use of the platform with clear workarounds or alternatives. For example, a feature is not working but there are workarounds or they are non-critical.

P4: User queries or non urgent problems that will be addressed using the defined support process for user support. For example, these are often feature requests.

Response & resolution times #

3. Service Level Agreement #

Support availability #

Service availability support (Priority level 0-1) is 24/7. Customer support (Priority level 2-4) is available during business hours. Customer support requests raised out of these hours will be addressed within the next working day.

Support channels #

Customer support is available via the following channel:

E-mail: support@iov42.com

Incidents and support requests raised outside of these channels are excluded from response time SLAs until they are opened via the official support channels. Any requests raised outside of these channels are not guaranteed a response.

Support escalation routes #

Customer support escalation is available via the following channel:

Email: support-escalation@iov42.com

Incident Reporting #

In the event of a P0 incident, iov42 will communicate a full incident report to the users of the Software within 3 business days. Where it is under active investigation, a summary will be published with further scheduled updates and actions outlined.

Maintenance #

From time to time iov42 may need to carry out routine maintenance to Interu. Although these generally do not directly impact users, iov42 reserves the right to take Interu out of service during the duration of these planned works. These works are deemed to be outside of the uptime and performance guarantees. Where Interu is taken out of service a holding page will be presented to users.

Maintenance may take place:

• between 18:00 - 22:00 (UK time) Monday to Friday; and
• at any time on Saturday and/or Sunday (UK time).

Where there is a planned outage of service, iov42 will communicate this two weeks in advance. Emergency maintenance will be communicated as early as reasonably possible and, where possible, critical maintenance will be avoided at times which clash with important EUDR deadlines.

System performance metrics #

iov42 undertakes that the system will run in a performant manner for users that meets the minimum system requirements. These metrics are recorded via monitoring systems in use by iov42 and will be used to ascertain if performance KPIs are met.

Application availability #

The application availability percentage is calculated on a weekly basis.

In the event that an Interu outage prevents the licensee from submitting a required DDS to TRACES (in the case of EUDR), the Interu team will pro-actively support the licensee and, where technically possible, provide an alternative method or workaround. Interu and iov42 cannot be held responsible for the stability of 3rd party services such as TRACES (the EU’s Information System) or AWS (Amazon Web Services, our hosting service provider). Interu will not directly submit DDS into TRACES on the licensee’s behalf in the instance of an outage. However, we will ensure that we support the licensee’s own team to submit directly into TRACES.

SLA availability failures #

In the unlikely event that the licensor misses the availability levels outlined above, we will provide a credit system per the below structure:

4. Data retention and residency #

Data residency #

The software stores all data within data centres located within the European Union and is subject to EU data protection laws. iov42 will not, without prior agreement with users of the platform, transfer, or cause data to be transferred to entities outside the European Union, with the exception of 3rd party processors as outlined in the list of data processors in the Interu Terms and Conditions. This excludes data processing carried out by the end user, such as downloading documents and amending data.

Backups #

The Interu system stores data in two ways: document data (created by user uploads) and systemic data (stored in a database). Each type has its own retention and backup policy. Both types are regularly backed up, enabling full recovery of historical data if a data loss incident occurs.

Backups are maintained within a rolling retention window, allowing restoration to any point within that window. Unless exceptional circumstances arise, we will always restore data to the most recent known good state.

This backup approach ensures that data remains recoverable unless it was deleted before the current backup window. For example, a document deleted 40 days ago would not be recoverable from our 30-day retention window.

Document Data
Document data is backed up in a continuous fashion, with documents generally being backed up within a minute of the document being stored. iov42 undertakes to hold at least 30 days of Document Data backups.

Database Data
Data held within a database is backed up on a periodic basis in line with industry standards. iov42 undertakes to hold at least 30 days of full Database backups.

Backups are held in a secure storage medium separate from the database server storage. The backups are replicated across multiple geographic regions.

Restoration policy #

Restoration of backups are only used in the event of major issues within the software platform, and is carried out at the sole discretion of iov42. iov42 makes no guarantees that in the event of a data restoration being carried out that data will not be lost that was entered prior to the event requiring a data restoration.

The Interu platform stores client data in a central database, giving each tenant a secure and segregated storage space; however, this means that we are unable to restore individual database records, for example, where individual records were accidentally deleted due to user action, either via the API or the web application.

5. Security #

iov42 warrants that the Software is both developed and hosted in a secure manner, in line with industry best practices. This includes automated security testing, intrusion detection and other systems designed to both protect and mitigate against security incidents.

Duties and limitations #

iov42 takes every reasonable precaution to ensure the security of the software; however, they cannot be held liable for any damage, outage or loss of data caused by security issues caused by, or exacerbated by, lapses in customer security. Please refer to the Interu terms and conditions for further details.

In the event of a security breach, iov42 will take all necessary steps to remediate the issue. This may require unscheduled downtime. In addition, within three working days of a breach being identified iov42 will:

• Inform all customers of Interu in writing of the date, time and affected systems of the security breach.
• Advise on the potential impact on customer data, including possible data egress.
• Advise on any additional mitigations that may be required, such as password changes.

iov42 will, within a reasonable period of time that allows for a thorough investigation, publish a full report of the security breach. iov42 may in the course of such an investigation retain the services of 3rd party consultants to aid in the investigation.