With increasing number of cloud and mobile based apps companies are increasingly moving their core data and processes out of local control and under the control of a cloud-based provider.  Often companies assume the responsibility for security and data loss prevention lies with the provider however in UK law this isn’t the case (see the ICO guidance for reference).  Have you actually reviewed those terms and conditions with providers to ensure they are responsible legally for your data and are acting as a data processor?

The focus of this blog is two of the core legal requirements as explained by the ICO:

  • Your measures must ensure the ‘confidentiality, integrity and availability’ of your systems and services and the personal data you process within them
  • You also need to ensure that you have appropriate processes in place to test the effectiveness of your measures, and undertake any required improvements.

Essentially these state that you must ensure the application being used to provide access to and store your data should ensure the confidentiality, integrity and availability.  It also alludes to the fact you need to verify that this is the case and continue to monitor and improve.  This of course is balanced by the risk to the business and the risk of data loss from a cloud based system.

Determine Risk

Step 1 – The first action we would recommend is to list all of your application that are used to hold or store your clients data (this could include any system that processes that data if even temporarily) – we have created an example list of systems to include but this list is not exhaustive:

  • Email Clients and Servers (including email marketing such as mailchimp)
  • CRM system (either cloud based or locally stored)
  • File systems (either cloud based such as google drive, SharePoint or local access databases or Excel files)
  • Business systems – a system you use to help manage your business (for example HubSpot, Xero, QuickBooks, bespoke systems)

Step 2 – If you are not comfortable determining the risk associated with each system then we suggest asking for third party assistance (for example Matter of Software provide technical consultancy services) to complete.  In this step you will list what data is stored in each system and what security, recovery and availability service level agreements (SLA’s – these are the targets the company who is providing the service will aim to achieve – they are not guaranteed in most cases).

Step 3 – Next we examine the list created in Step 2 and associated a risk factor for each system.  We suggest allocating a data risk factor (the more personal the data the higher the risk factor) and a separate risk factor for

  1. confidentiality – what mechanisms are in place to keep the data secure at any point (question do you have external validation that this is the case?),
  2. integrity – what mechanisms are in place to ensure data hasn’t been changed/manipulated
  3. availability – what mechanisms are in place to ensure you can access your data when you need it and importantly can get access to your data for a supplier failure

Step 4 – Hopefully as part of the review you have identified the prioritised list of systems based on risk to data and hopefully identified that all systems are low risks against the three points.  More often than not this will lead to more questions – the process of determining the risk of a system will probably lead to the question – I don’t know.  You will look over those contracts, examine what backups are taken, explore how you can access your data and most likely find somewhere that you secure data is being secured on an insecure Excel sheet on a local machine.

This step ensures you review each of the systems to ensure that any of the identified gaps in terms of requirements are met with a plan to close those gaps.  Perhaps you need to encrypt emails (or avoid emails for certain communications) or perhaps you need to review existing contracts with providers.

What about apps with the greatest security risk?

If you have identified (or more importantly been unable to satisfy yourself that a system is secure) one or more applications that you wish to perform more validation then you should put together a plan to lower the risk.  These can include a number of options which you will need to determine at least the effort, risk and cost.

Options include:

  1. Stop using the application – if its redundant or not needed then best to remove sensitive data and close down
  2. Switch to another application – if you have multiple applications that can perform the same tasks then perhaps best to switch applications
  3. Reduce the risk

Reduce the risk

In order to determine whether a cloud-based application (provided by a third party or internal) posses a security risk you would normally perform a series of tests such as:

  • Static Code Analysis (reviewing the software code for weaknesses)
  • Penetration Test (using a human or machine to test the software for known vulnerabilities)
  • Compliance Testing (ensuring the software used and components
  • Load Testing (ensuring the software remains secure and available under heavy utilisation)

Good practice suggests that all of the above should be performed a number of times, during initial release of any software and then on a regular basis to ensure the software is tested against the latest vulnerabilities.  Code and Load-Testing should be re-checked after any change in function, Load-Testing, Penetration Test and Compliance Test should be re-checked after any network changes and Compliance Testing and Penetration Test should be repeated at regular intervals.

Security Testing

Matter of Software provide a service to enable new and existing clients to perform a security analysis of any web-based application for a fixed low cost.  Our service provides an initial security analysis (see below for more details) and the option for a regular weekly scan to ensure the solution remains compliant with the latest threats.

Our software is intelligent in that it executes the core user journeys through your system ensuring that pre and post logged in pages are equally checked.  Our CREST approved reports cover all known OWASP Top 10 vulnerability checks.

More details on our service are available on our website.