Purpose of this document
The purpose of this document is to define the data management approaches being undertaken in the provision of the ARM service. It also highlights the areas that client organisations should be considering, although it is not intended to be exhaustive on this topic.
This document is written in response to the General Data Protection Regulations (GDPR) 2018. It does not specifically address the needs of the Data Protection Act (DPA) as this will be obsolete shortly after release of this document.
Background on the GDPR
The GDPR can be summarised in four strands :-
- Access to your own data - the ability to better understand how your own data is processed in a clear and understandable manner.
- Data retrieval - the ability to extract your data in a usable form to be able to move to a different service
- Right to be forgotten - the right to have your data deleted when there no legitimate grounds for retaining it.
- Right to know when your data security has been breached
Security of data in transit
ARM is an online service, provisioned via a website. The traffic to and from the website is encrypted using HTTPS, with a recognised and in-date certificate providing the reassurance of a "green padlock" in most browsers.
If a client browser does not support HTTPS, ARM will decline to serve the page, preventing any clients on out-dated or unusual browsers (eg e-TVs) from inadvertently causing a security breach.
ARM can be (and typically is) configured to use an external SMS provider for reaching responders. Likewise ARM can be (and typically is) configured to use email to contact responders.
Encryption of the traffic to an SMS provider is subject to the configuration of the SMS provider, and is outside of the responsibility of ARM. Likewise any onward transmission of the SMS data is outside of ARM's control.
Data coming in to ARM from the SMS provider will be subject to the same encryption as standard ARM web traffic.
ARM does not handle incoming email. Any email received to the noreply@bigy….. address will receive an auto-reply discouraging the user from repeating the action. This email traffic is not encrypted, and any such emails will be deleted in a regular purge of the account.
ARM can be configured to send outgoing emails to responders, which can contain personal information depending on the client configuration. This email traffic is encrypted at the point of transmission from ARM to the outgoing mail server. Any encryption or storage obligations beyond that point are beyond the scope of the ARM service and should be considered to be the responsibility of the customer organisation.
Cookies are small packets of state information stored within your browser's local cache. These items of information are only used in ARM in order to persist your login information between pages and between sessions. When a user logs out of ARM, the cookie is either cleared to an empty string or deleted (implementation is browser specific).
A small amount of information is held by ARM for logging live activities and any errors encountered. This information includes the site, client User ID, client IP address and the URL requested. This information allows the ARM administrators to swiftly identify any issues with individual logins. This information is not persisted to permanent storage, and is wiped when the rolling cache is full, or when the site is restarted, whichever is first. No information such as passwords is stored in the diagnostic logs.
Changes made by a user to any entity, such as to a user record, a tasking record or similar, is logged against that item with an identifier of the user that made that change. This information is deemed part of the record of that changed item, and is persisted for the lifetime of that item. When the item is deleted, the record of the changes to that item will also be deleted.
Password changes are not recorded in plain text in the evidential logs.
Data sharing with third parties
Messages internal to your organisation, but outside of ARM
Data held by ARM can, if so configured by your organisation's ARM Administrator, send information outside of ARM to third parties in the form of SMS or email messages. These messages would typically be to members of your organisation to either instruct them to take an action during a response phase, or to take an action for administrative purposes. It is the responsibility of the client organisation to ensure that this is appropriate given your internal privacy policies.
The encryption of this data is discussed in the encryption section above.
Information shared with other users of ARM
If so configured, your organisation can request support from other organisations within ARM. This will involve sharing the details of the request with the partner organisation.
In an approaching release, partner organisations will be able to choose to manage on-site resources in a shared operational picture. This will involve knowing the basic details of responders assigned to that tasking, their welfare state and will also allow shared tasking lists.
In both of these cases, the information shared will remain in ARM, although partner organisations could copy and paste it into an uncontrolled location.
Likewise in both of these cases, this sharing will only occur if explicitly configured by your ARM administrator and if invoked by your controller for a specific incident.
Information sharing outside of ARM
Information summarised in aggregate (for example, XXX users currently use ARM, YYY hours of operations were coordinated through ARM in the last week) may be used by BigYellowDesign Limited for the purposes of marketing ARM. No personally identifiable information will be included in this data.
Unless specifically forbidden, BigYellowDesign Limited may identify client organisations of ARM, for example "BigYellowDesign is proud to support Organisation ZZZ".
Legal and Criminal investigations
BigYellowDesign Limited will comply with any properly presented and legally compelling requests for information as part of criminal or legal proceedings. Unless specifically prevented from doing so, we will advise the client of the action that has been taken and the information that has been shared.
Deletion of data
Deletion of data following the cancellation of the ARM service
At the completion of any notice period after a client organisation terminates their ARM service, access to the client site in ARM will be removed. The data will be retained within ARM for a period of 28 days (unless otherwise agreed) to allow for the organisation to bed into the new service and to have identified any data which has not been migrated properly. Once that period has passed, the client dataset will be deleted from the live site. The rotating backups will then gradually purge that data over a period of up to two months.
Data held by BigYellowDesign Limited about the organisation, such as invoice data and billing information, will be held for a period in accordance with appropriate tax and audit requirements.
Deletion of data held by a client organisation
ARM provides the client administrators with the ability to delete data and/or delete users and/or tasking information from ARM. It is the responsibility of the client organisation to ensure that they do not keep information beyond that which is necessary.
Necessity of storing data
ARM requires certain fields to be able to operate using all functionality. This includes end-user contact details, location of an incident etc. The client organisation administrator can add or remove fields within ARM such that the minimum data required is held. The client administrator can also generate reports to identify data that can be removed. For example, this could include a report to highlight where tasking location information such as an individual's address is still held when the tasking was closed more than XXX months ago. BigYellowDesign Limited provides the ability to delete data, but will not be itself managing the deletion of individual data fields within ARM, this is the responsibility of the client organisation and is subject to the individual client organisation's privacy and data management policies.
Physical locations of data
The ARM site is served from a web-server hosted within the Microsoft Azure service from servers physically located within the UK. Data will be held within a database hosted within the Microsoft Azure service. This data is replicated on two servers, one in north Europe, one in west Europe. Backups of the data are held on encrypted hard drives located in the UK.
ARM is hosted as a MS Azure app service. This service includes regular service patches and security updates. The ARM software itself is released through a CI & CD process, and automatically uses the most recent patches for the development environments, third party software and SDKs. A suite of automated unit, system and integration tests are run as part of the release process, and only builds which pass all criteria will be published to the live environment. Daily backups of the data held in MySQL are conducted automatically as part of the hosting service, and regular backups are taken to offline encrypted hard drive storage.
In the event of discovery of a data breach, it will be the responsibility of the director(s) of BigYellowDesign Limited to ensure that communications are sent to the representative of the affected organisations as quickly as possible, and in no case later than 48 hours after confirmation of the breach. Details of the breach and the information affected will be shared as quickly as possible so that any potential mitigatory action can be taken by those affected.
Details of the breach and any remedial action taken to improve security will be provided to the client organisation as soon as it can be shared without increasing the risk of further breach.