Cyber Information Governance in IoTUK Projects

Cyber Information Governance in IoTUK Projects

This blog forms part of a series that looks at the technical experiences of three IoTUK projects that ran between 2016 and 2018.

Each of the three projects implemented their own IoT technology platform and in this blog we’ll explore how they managed challenges around Information Governance and cyber security. You will learn about the technical and paper based challenges faced by the projects.



CityVerve is the UK’s smart cities demonstrator, based in Manchester. CityVerve explored how IoT technologies and the forging of new relationships between the public and private sector can make a city truly smart. The resulting solution was a Platform of Platforms connected by a central portal that exposed data from different elements of the city. The data was open to 3rd party developers allowing them to create new and innovative apps.  

Diabetes Digital Coach (DDC) is an NHS IoT Test Bed project and has been developed by consortium of 10 technology and evaluation partners, led by the West of England Academic Health Science Network (AHSN). DDC offers an online service to help people with Type 1 and Type 2 diabetes manage their condition and cut the risk of complications. It is available via computer, smartphone and tablet and brings together a number of digital self-management tools, which provide personalised support. When people sign up for an account with the Diabetes Digital Coach, they provide information about themselves, their health, lifestyle, and how they currently manage their diabetes. The Coach then suggests the most appropriate tools to suit their individual needs. The Coach features five tools which have been carefully selected by both healthcare professionals and people with diabetes;  this ‘menu’ covers self-management education, dietitian support, optimising physical activity, insulin and glucose management, and a personal health record.

Technology Integrated Health Management (TIHM) is an NHS IoT test bed aiming to transform support for people with dementia and their carers. The collaboration involves partners from the health, voluntary and technology sectors. Each family in the trial was provided with a home technology pack that was suited to their particular needs. Like the DDC portal, TIHM connects different technology partners but here there is real-time correlation between different data points allowing insights to be gleaned. Any unusual signs are flagged to clinicians who will decide on the appropriate action to take.



Information Governance

Information Governance is a set of processes that define how personal data will be managed. Each of the three projects assigned a Data Protection Officer (DPO) to manage the task of ensuring compliance with regulations such as GDPR.

At DDC, the Data Protection Officer ensured the project met the following criteria.

  • ISO 27001 certification – a set of standards relating to Information Security Management Systems.
  • GDPR compliance– From 25th May 2018, all companies that process personal data must comply with the General Data Protection Regulation.
  • Assurance tracker – Track the responsibilities of the Data Controller and/or Data Processor. Some companies will fall into both categories. Definitions can be found here.
  • Technical validation – Assign a 3rd party organisation to independently validate privacy and security requirements of the solution. For DDC this included a code audit and penetration testing (PEN). Utopia and Appcheck tools are able to provide useful outputs to testing teams.
  • Data breach plan – Document the steps to take if a data breach occurs.
  • User management – Users were managed centrally with registrations taking place within the portal. A single-sign-on process was used to authenticate users with all the partner applications.

The TIHM project handled clinical data in addition to the activity data we saw in DDC. This required TIHM to implement NHS guidelines on Information Governance. The NHS provides a toolkit to allow organisations to measure their performance against the National Data Guardian’s 10 data security standards. 

CityVerve ensured they were able to comply with GDPR right from the start of the project. The Information commissioner has published a toolkit to allow organisations to assess their compliance with data protection law.

At the earliest possible stage, the team implemented a paper-based Privacy Impact Assessment that was carried out by independent auditors from Manchester City Council. All CityVerve partners went through the assessment. The project had an ethics board that advised all members on aspects of Information Governance. Due to the large scale of the project, individual teams were able to receive direction from the ethics board but were free to make their own decisions.

CityVerve planned to open up its Platform of Platforms to 3rd party developers so additional safeguards were built into the system.

  • No personal identifiable data was allowed to be exposed. For example, for a cycling project that used IoT enabled lights, no project personnel knew which light belonged to which bike. The frequency with which data was logged by devices was also carefully managed so as not to give away a person’s identity. For example, the GPS location of the cycle lights was only shared once a day.
  • Security settings were enforced for users. For example, when lights were installed on bikes, users were forced to complete all security tasks during setup.
  • Some of the services that made up CityVerve were related to Healthcare. These platforms had similar constraints to TIHM and DDC but were not tightly coupled with the central portal. To keep health data partitioned from the rest of the environment, health applications could take data from the central portal but were restricted from sending data to it.

Technical aspects of security and privacy

Both DDC and TIHM were handling data related to health and needed to ensure that this data was handled securely across their entire solution. Data in motion over the air or between data centres was kept private by encrypting using Public Key Infrastructure (PKI)

  • Public keys were used to encrypt and Private keys were used to decrypt
  • Public keys were provided by the team managing the central portal
  • Each technology partner had their own Private key

Data at rest, typically in databases was also encrypted during storage.

Across the three projects, APIs were used to provide access to the central portal. Keeping this interface secure requires an API management solution. Tyk was used to manage and monitor the APIs because it wasn’t tied to a particular cloud vendor. Tyk ensured that only authorised developers used the platform (using key based authentication) and within the rules defined by the consortium.

To reduce the risk of malicious attacks, Penetration testing (PEN test) at CityVerve was carried out by the major partners, Cisco and BT. These companies used their existing enterprise tools and procedures to test the platform. DDC used an external independent company to conduct PEN testing.

Lessons learned


  • Ensure the project allocates a budget for security testing
  • Design securely from the beginning
  • Test security from the beginning
  • Ensure the project has a data breach plan
  • For added security, partition data for each user using a user centric database
  • Have key based API access to manage and monitor each developer’s usage
    • API management should be independent of the cloud hosting service if the solution needs to be portable
  • Physically lock down servers
    • Project staff should not have physical access to the data centre
    • Access should be limited to remote read/write only
    • Server cabinets should be locked and the keys to cabinets should be locked in a separate location.
  • Make development easy for 3rd parties
    • 1st party developers, e.g. your own staff – Companies can enforce ways of working
    • 2nd party developers, e.g. contractors – Companies can enforce ways of working
    • 3rd Party developers, e.g. public developers – Companies can’t enforce ways of working so need to make the APIs easy to use. Developers tend to use a platform if they can quickly develop basic apps. Additional functionality is normally added later.

In the next blog in this series, we’ll take a closer look at the platform architectures deployed by the test beds.

Don’t forget to follow us on Twitter to keep up with this series IoTUKNews.

Idris Jahn
No Comments

Post a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.