The Multi-Agency Information Sharing Protocols (MAISP)
Sharing non-personal data
The handling of non-personal data is not regulated by legislation. However, there is a requirement to share non-personal data in certain circumstances such as when sharing for the purposes of furthering and advancing the health and welfare of the Surrey population (S.82 of the National Health Service Act 2006) or for the purpose of Local Government Reorganisation (LGR). There is still a duty of care that needs to be considered when sharing such data between organisations. The following is a guide to help organisations to recognise their obligations and good practice when processing non-personal data.
What is personal data?
Personal data is information that relates to an identified or identifiable living individual.
While personal data is regulated under laws like the UK General Data Protection Regulations (GDPR), non-personal data is not subject to the same protections because it does not relate to an identifiable person.
What is non-personal data?
Non-personal data is information that does not relate to an identified or identifiable natural person, or data rendered anonymous, so individuals are no longer identifiable. It includes aggregated, statistical, or technical data, such as weather or traffic patterns, that cannot be linked to a specific person.
Share data appropriately
Non-personal data will be shared in accordance with legal or security frameworks and standards but will be open and accessible wherever possible.
Different types of non-personal data
Anonymisation
Anonymisation is when a person is no longer identifiable in data. Data anonymisation can be achieved through randomisation.
When randomising, removing the link between the data and the individual means that the data is no longer identifiable but is still valuable to the team performing data analysis.
Example: You hold a dataset of all children living in Surrey who use Home to School Transport. This includes their names, dates of birth and full addresses.
For the data to be properly anonymised you would need to fully remove the names of the children, their dates of birth and the addresses, including postcodes. You could consider keeping the year of birth and a partial postcode, such as GU1, as this information would not be able to identify an individual.
Aggregating Data
Aggregating data combines data about individuals so that the data shows general trends, overall figures and averages rather than any individual level data.
Example: Using the above example, an aggregated dataset could show the total number of children who use Home to School Transport for the different areas in Surrey.
Pseudonymisation
Pseudonymisation refers to techniques that replace or remove identifiable information. Pseudonymisation means that people are not identifiable from the dataset itself. However, they are still identifiable by referring to other, separately held information. Unlike anonymised data, pseudonymised data is still personal data, and needs to be handled in line with data protection legislation.
Pseudonymisation is a technique that replaces information that directly identifies people, or de-couples that information from the resulting dataset.
Example: Pseudonymisation may involve replacing names or other identifiers (which are easily attributed to people) with a reference number. For example, removing or masking direct identifiers within a dataset such as replacing a name with a random number.
Using the example above, each child who uses Home to School Transport could be allocated a unique reference number and an index list could be kept separately which explains which reference number links to which child. A pseudonymous dataset could then be created, which would look similar to the anonymised example above, with year of birth and partial postcode for each child as well as the unique reference numbers. While this does not appear as being directly identifiable, individuals are identifiable when paired with the separately held document, so it is pseudonymous data and must be handled as personal data.
When does Pseudonymised data become non-personal data?
When the keys, such as reference numbers, are completely removed from the data set or the link between the reference number and an individual no longer exists. As in the example above, the index list is deleted.
Checklist
Use this checklist to help you govern good data sharing of non-personal data. This list is not exhaustive, and you may wish to consult with your subject matter experts in your organisations.
- What is the purpose of sharing the data?
- Think about outcomes of the data and what uses it will have to inform service research and decision making.
- Such as does this data support agreed LGR objectives and outcomes?
- Who is it that is requesting the data /who are you wanting to share it with?
- Consider your own organisation’s policies and guidance for limiting the sharing of what could be considered as commercially sensitive data
- Consider if there are any commercially sensitive parameters to the data
- Consider the organisation and their purposes for requesting the data
- What is it that you are wanting to share: postcode, age range, anonymised personal opinions, financial data?
- Clarify with partners the exact type or category of data that is to be shared, such as first three letters of a postcode, age range, anonymised personal opinions, financial data.
- Consider whether you are sharing only the minimum data required to achieve the purpose.
- Could the data be further aggregated or reduced?
- Agree who will own the data and be the responsible owner
- Who will be making the decisions on and about the data and any authorisation process required?
- Onward use and disclosure of the data
- Agree if there will be further sharing of the data and any onward use of the data.
- Consider whether you would be comfortable if this data was made public.
- Are you will be able to reuse it in some form?
- Has the original purpose changed if you agree to reuse the data - either for commercial gain or other reasons?
- Examine data quality
- How authentic and genuine is the data, for example, is it historical data? Verify the source and check for accuracy.
- Freedom of Information Act (FOI)
- Public sector organisations are subject to FOI - are you clear about your obligations to comply with the FOI Act and agree on working together to process, authorise and disclose the data held?
- Risks to disclosure or sharing of data
- Consider the risks to the data if onwardly shared or disclosed, such as harm to the public authority or third party
- Is the information commercially sensitive and why?
- Has the information been provided in confidence?
- Is the information being shared for the purposes of discussion in a ‘safe space’?
- Is the information covered by Legal Professional Privilege?
- Consider whether the data has been appropriately classified, for example, Official or Official-Sensitive, and ensure that all parties understand what handling, storage, access, and sharing controls are required based on that classification.
- If you are sharing anonymised data but due to data matching could data be compromised and is likely to reveal personal data?
- Consider if the data you are using can be matched with other data whether inside or external to your organisation that could reveal the identities of people. Pay particular care to data sets that contain values less than 5.
- Data Retention
- Have data retention and deletion arrangements been agreed and communicated?
- Most data should be retained only for a defined period based on legislative requirements or an identified business need.
- Security
- Consider the physical transfer of data.
- Non-personal data does not have security requirements in the same way as personal data, however, you should consider who you are sharing it with and use the above checklist of risks.
- Consider the arena where the shared data is being stored and its security and levels of access.
- Version control
- Operate version control to ensure that everyone is working off the most up to date data and a master copy is held as duplicate sets tend to cause inaccuracy and confusion.
- Data Quality
- Good quality data is data that is fit for purpose. Data values should be right, but there are other factors that ensure data meets the needs of its users. Having good quality data does not mean every value must be perfect; good quality will be different for different data sets.
- Ethical use and unintended consequences
- Have you considered whether the data can be used in ways that lead to unfair outcomes or misinterpretation?
- Have ethical considerations been reviewed?