1. UKFSS (Software as a Service) service definition.

Provided by MacLaren West Ltd.

Publication Date: 03 May 2022

2. Overview of the service

UKFSS is a Cloud based service which manages the details and results of all food and animal feed samples submitted for analysis and/or examination by Official Control Laboratories (OCLs) on behalf of Competent Authorities. UKFSS was developed as a collaboration between CAs, Public Analyst laboratories (PAs) and the Food Standards Agency (FSA). This service operates in real time enabling CAs to submit sample datasets via a compatible client application that transfers this information via an encrypted API to the service. This data is then routed to the designated OCLs which are responsible for undertaking the analysis/examination of these samples as required by legislation. OCLs collect the samples from the cloud service and process them. On completion of the required analysis, the OCL uploads all sampling and analysis data into the central UKFSS service. Completed datasets are made available to the originating Competent Authority and stored in a Reporting Database for further analysis at a local, regional, or national level. All access to the Cloud Service is performed through a suite of APIs.

Diagram 1: Data flow throw the UKFSS Cloud Service.

3. Data security and disaster recovery.

With the service being hosting on the Azure cloud platform, we attain a high level of resilience. Continuous backups are taken and can be restored to any point of time. We take daily offsite backups which are encrypted and stored outside of the Azure infrastructure.

In the event of an unrecoverable loss of service, we can recreate the hosted environment within four hours. This includes Virtual machines, web services, worker processes, etc. No data would be lost in such a scenario.

We have full documentation on how to restore the service. The source code for the service is stored in a separate cloud-based source control system and can be restored to a new operational system quickly.

4. Onboarding and offboarding support.

In the event of a contract expiring, we provide the following:

• We maintain a comprehensive guide that documents the process to transition the service from our cloud infrastructure to another host.

• We provide full backups of all data we retain for clients on request

• We will assist in the transition and endeavour to leave our client with a functioning system

5. Service constraints

All maintenance of the service is carried out during periods of minimum usage, such as weekends or evenings. Only rarely does any maintenance task require that the service is taken offline.

The service handles clearly defined datasets through an established and predictable workflow. While there is some customisation possible with how users engage with the services, the scope of this is limited.

6. Service levels

Service provision meets the following standards:

• Service uptime of 99.94% or greater: with system being inaccessible for less than thirty minutes per month (excluding scheduled downtime).

• 90% of all support calls are resolved within the relevant SLA targeted time as detailed in “Resolution times for incident types” below.

We provide the following levels of support for all users of the service:

• Availability of support service for all lines of support (email and

  telephony) between the normal working hours of 9am and 5pm Monday to Friday (excluding statutory public holidays) so that all calls are logged immediately.

• The caller is given a reference number, the assignation of incident

  type (i.e. Major, Moderate or Minor) and the expected target date for resolution.

• Support calls from all users of the SFSD and SND will be handled by

  the Service Provider within the following Response and Resolution timeframes:

7. Response times

We, on receipt of a call logged on behalf of FSS or direct from a user, will provide an immediate response. The caller shall receive a call reference number and an assigned type of the incident as Major, Moderate or Minor and a target date for resolution, as agreed with the client.

7.1. Resolution times for incident types are as follows.

• Major – within 24 hours of receipt of call. Examples of Major

  incidents:

  • Operational failure of the service within the agreed operational

    hours, that results in users being unable to access or use the service.

  • Provision of data reports to users to support urgent and time

    bound queries (e.g. Freedom of Information requests), and urgent operational issues when standard reporting tools are not available.

  • Tracking of samples as part of set up testing

  • Providing user details to new users

  • Uploading new Food Categorisation, Determination and Outcomes

    Codes tables as required in the event of food incidents.

• Moderate – within 5 working days of receipt of call. Examples of

  Moderate incidents:

  • Support to Competent Authorities with mapping of Management

    Information System data within SND.

  • Assistance to Competent Authority users, their IT providers, and their

    Management Information System providers to resolve issues with their connection to the service.

  • Outcomes table upload.

  • Category tree upload.

  • Investigating technical issues with LA or laboratory use of the

    service.

  • Provision of non-urgent data reports to service users when

    standard reporting tools are non-operational).

• Minor – within 10 working days of receipt of call. Examples of

  Minor incidents:

  • Tracking samples for a competent authority to compare with local

    records.

  • Tracking historic data at labs.

8. Technical requirements

There are no explicit technical requirements for accessing the service. The service is primarily accessed through a set of modern APIs. Support for Legacy proprietary APIs are also supported. These legacy APIs can only be accessed through specific Windows applications what were written to use them.

9. Outage and maintenance management

The service is monitored continuously for an independent source and any outages are reported in real time to support staff through an API and via email alerts,

9.1. Hosting options and locations

All Data is located and processed with the Microsoft Azure Cloud environment exclusively on infrastructure hosted with the UK.

9.2. Access to data (upon exit)

Data will be provided as a full database backup file for each database included in the service. Help will be given to ensure that backups are restored and accessible if requested.

We have a full transition guide which will be provided to the client on notice that the contract will expire and not be renewed. We will engage with any future supplier to implement the process detailed in the transition guide upon request.

We will provide all data to the client and ensure that it is accessible.

9.3. Security

MacLaren West follows security standards as advised by the Open Group Architecture Framework.

• Authentication: Authentication is applied on all systems under our control.

• Authorisation: Role base authorization is used to manage user access to resources,

• Audit: All critical systems include comprehensive auditing. Audits are run regularly, the results of which are reviewed for compliance to company standards.

• Assurance: We maintain automated test suites which we use to verify that all required security policies remain in place. We run automated audit reports on all infrastructure and take action to apply security and performance suggestions from these audits.

• Asset Protection: All data is encrypted at rest and in transit. All data is protected with authentication and authorization rules.

• Administration: All systems have configurable security policies which can be updated based on specified requirements. This includes adding, updating or removing users and roles.

• Risk Management: We are a risk adverse organization. Our highest priority is the security and integrity of data held on behalf of our clients and all reasonable precautions are taken to protect it.