ÌìÃÀÓ°Ôº

Who these principles are for

These principles are useful to anyone developing a system or service that processes or shares personal data.

They’re mainly for people who work in government organisations and arm’s length bodies. This includes:

• chief digital and information officers (CDIOs)
• chief technology officers (CTOs)
• chief data officers (CDOs)
• senior responsible officers (SROs)
• chief information security officers (CISOs) and cyber security professionals who advise on cyber security risk management and implementation of security policies, standards and procedures
• data protection officers (DPOs)
• data owners
• data custodians
• data stewards
• Information Asset Owners (IAOs)
• data analysts and data scientists
• anyone whose role involves delivering digital services –Ìýfor example, product owners, software developers, designers and project and programme managers
• IT operations roles (DevOps)
• technical, data and security architects
• commercial and legal teams responsible for ensuring the safe handling of personal data is included in relevant contracts

Some of these people will be responsible for ensuring the principles are followed, while others need to consider the principles when designing, building and operating digital services.

Government services operate in complex, cross-domain environments. This guidance sets out cross-functional responsibilities in one place, so you can use it to support effective cross-functional working.

The principles are not about day-to-day handling of individual items of personal data, or about risks to physical information.

Why these principles are important

If you work in government or the public sector, you have a duty to protect the personal data you hold about individuals.

You must comply with all UK data protection law. This requires organisations to handle personal data according to to protect against unlawful or unauthorised processing, access, loss, destruction or damage.Ìý

The government holds data for a subset of individuals who are at greater risk of harm if their data is breached. These risks may not be obvious to government practitioners.

The principles in this guidance will help you to identify these types of heightened risks in your service, and implement controls to mitigate them.Ìý

For example, a government service might process personal data about people in witness protection schemes, government staff in sensitive roles or a high profile public figure. The impact of a personal data security breach for these individuals could be catastrophic:

• a victim of domestic abuse could be targeted if their new address is discovered by their former partner
• a serving judge could be in danger if their home address becomes known to a person they previously convicted

When personal data is shared outside an organisation, or when different sources of data are combined, the risk of accidental identification of vulnerable or at-risk individuals increases.

But this does not mean data should not be shared, as not sharing data can also have impacts. For example, an individual who presents a risk to public safety might not be identified if their data is not shared by the relevant agencies.

Following these principles will ensure your service handles personal data more securely, and that you share this data safely across different departments and agencies. This is vital to maintain public trust and deliver services effectively while safeguarding individuals from potential harm.

Definition of personal data

is any information relating to an individual that can identify them, or is specific to them, including:

• names, dates of birth or addresses
• such as someone’s race, ethnicity, health or politics
• information about someone’s

Special category data and information about criminal offences are subject to stricter rules.

Personal data also includes numbers and codes that are uniquely assigned to an individual –Ìýfor example, National Insurance numbers, NHS numbers or customer numbers. IP addresses, session IDs, user IDs and other machine-readable information pertaining to a person can also be considered personal data.Ìý

For more information about when and how to apply the ‘personal data’ descriptor to information, refer to the Government Security Classifications Policy.

Identify your data assets

Before thinking about risks to personal data, you need to identify the data assets your service will handle and which of these include personal data.Ìý

A data asset is a container that holds one or more data resources. The most common resources are data sets (individual, structured collections of data)Ìýand data services such as Application Programming Interfaces (APIs).

Creating an or identifying assets within your data catalogue will help here. You should map out all the data flows in your service, especially those involving personal data, including:

• how personal data flows to and from external services
• how personal data is combined with other data sets

You should also consider whether any of your assets can be shared across government, and should be designated as an Essential Shared Data Asset.

Identify risks

When designing services that process personal data, you must follow the guidance on:

• to adopt a risk-driven approach
• to consider privacy from the start

This means you need to identify and understand the risks to personal data. You can then put controls in place to make sure your services operate within your risk appetite.

There are 3 broad categories of risk relevant to personal data security:

• loss of personal data (confidentiality)
• accuracy of personal data (integrity)
• access to personal data (availability)

These are risks to the personal data that your service stores and processes. There are also risks of sharing and not sharing personal data.Ìý

Each risk you identify for your service will have an impact on:

• people –Ìýprimarily the individuals whose personal data it is, but also their associates, friends and family
• organisations –Ìýincluding your organisation, but also organisations related to the individual, for example, their employer

For example, the impact of a loss of personal data to a vulnerable or at-risk individual could include:

• government staff in sensitive roles being harmed if the link to their employment is uncovered by hostile actors
• serving MPs or other public figures becoming targets if details of their family life or where they live are found out by extremists

Refer to the appendix for more examples of the types of risks and their impacts.

To help identify risks, it’s useful to think about the activity that requires data to be processed or shared, and then break that down into:

• the data involved
• the user who needs the data
• the environment the data is being processed or shared in
• the purpose for which the data is being processed or shared

For example:

• to process a payroll run, employee salary and bank account data must be shared by accounts users with a third-party, cloud-hosted payroll environment so that employees can get paid the correct amount (purpose)
• when providing a vaccination service, patient vaccination data must be accessed by health care professionals (users), in a one-to-one clinical setting (environment) so that the correct vaccinations are given (purpose)

The data involved in each activity will have characteristics, such as:

• whether it is personal data
• whether it contains special category data
• its specific data type
• its data quality
• whether it is pseudonymised
• whether it is a population scale data set
• whether the data subject has a sensitive role or employer
• its handling instructions

The users can also have characteristics, such as their:

• security clearance
• role
• skills, experience and ability to use the data appropriately

The environmental characteristics could include:

• ²µ±ð´Ç±ô´Ç³¦²¹³Ù¾±´Ç²ÔÌý
• time of day
• level of encryption
• mode of access
• hosting – for example, managed cloud, private cloud or on-premise

Along with the purpose of the activity, you can use these risk-relevant characteristics when defining security controls to mitigate the risks you’ve identified for your service. For example, only doctors are permitted access to full patient records when connected via an approved VPN.

Activities to consider

The Secure by Design framework recommends the you should do to identify and manage cyber security risks when designing your service.Ìý

The following activities are important:

• – identify your service components and data flows, and then as a team suggest and document where the vulnerabilities are
• – define the severity of each risk by assigning it a likelihood and impact
• for the risks that are outside your risk appetite, taking account of the risk-relevant characteristics

Carry out a if your service requires it (see Principle 4).

For more information, refer to the Orange Book and .

Principles: introduction

These principles represent the foundations required for safely and securely handling personal data when designing, building and operating digital services. They build on the government’s cyber security requirements for ensuring that public services keep data secure.

You’ll also need to factor in your organisation’s own policies and controls to fully mitigate the risks you’ve identified for your service.

For each principle, there is a range of best practice controls to consider using to achieve the outcomes. For each control, you’ll need to who is responsible for implementing that control.

The NCSC has technical guidance on that will help you implement your controls.

1. Plan your response to personal data breaches before they occur

An inadequate response to a data breach can undermine public trust, and might mean your organisation is not meeting its legal obligations.

You should aim to have:

• a standardised approach for reporting data breaches –Ìýthis will ensure that relevant authorities know about an incident before it’s reported in the public domain

• effective coordination with central government agencies
• a consistent response to prevent future incidents

Controls:

• agree roles and responsibilities for reporting data breaches

• ensure points of escalation are clear when incidents occur

• establish a cyber security incident response team (CSIRT) to handle cyber incidents that could involve a data breach

• define a process to make sure data breaches are reported to the relevant authorities – for example:
  • your organisation’s DPO and CSIRT
  • the
  • the – keep the threshold for reporting to ICO low, and, if in doubt, report it
• publish and promote the process for reporting incidents via internal and external channels in your organisation
  • for example, use the resources from the ICO’s and the government’s ³¦²¹³¾±è²¹¾±²µ²ÔÌý
• establish a lessons learned process to review incidents

The ICO is there to help organisations, and has resources to support you in the event of a personal data breach:Ìý

• Ìý

• Ìý

For more guidance refer to:

2. Minimise the attack surface when sharing personal data

You should aim to:

• be able to share data with confidence
• prevent personal data being compromised when it is shared
• avoid the risks of not sharing data – do not block data sharing unnecessarilyÌý

Controls:

• share data in place – do not create more places for data to be stolen from
  • for example, exposing your data via a secure data API means recipients do not need to take bulk copies of your data set and can query it in place
• data anonymisation – often it’s possible to share data without requiring any personal data to be shared
  • for example, to process a tax calculation it’s only necessary to share financial information without any personal details
• data pseudonymisation – if person-level data is required and cannot be anonymised, pseudonymise it before sharing (refer also to Principle 7)
  • for example, if provider and recipient use the same personal data pseudonymisation method, data about individuals can be joined without revealing their identity
• data minimisation – only share the minimum set of data that the recipient needs
  • for example, to process payroll you may only need to share a person’s email, payroll number, salary details and National Insurance number, not all their other personal details
  • check also for hidden personal data contained in metadata or hidden fields
  • consider if sharing only the changes to a data set is sufficient –Ìýfor example, when sharing address data the recipient may only need to know about recent changes of address rather than receive the addresses of all individuals in the data set each time
• share consistently – define a policy for sharing the data of vulnerable or at-risk individuals and make sure you’re consistent when sharing with all recipients (refer also to Principle 9)
  • generally it’s best to include the records of vulnerable and at-risk individuals when sharing data (with appropriate anonymisation, pseudonymisation and minimisation controls)Ìý
  • by removing high profile individuals from a data set before sharing, there’s an increased risk of them being identified if the data set is then joined with other data sets that contain their data
• share appropriately for the use case – analytic and operational use cases have very different requirements
  • for example, bulk file transfer may be appropriate for aggregate statistical outputs, but secure APIs will be better for operational workloads
• regularly review all personal data shares to make sure they’re still required

3. Make sure personal data is secure throughout your supply chain

You need to be confident that the third parties you engage can manage risks to personal data effectively. You remain responsible for any data breach at a third-party processor in your supply chain that compromises personal data you have shared.

Make sure that:

• all commercial agreements with third-party data processors in your supply chain comply with
• data hosted at a third-party processor complies with legal requirements and is secureÌý
• data shared with a third-party processor is subject to the same or a lower level of risk than when at source
• third-party processors understand their responsibilities when handling personal data and the impacts associated with data loss for at-risk or vulnerable individuals

Controls:

• keep an up-to-date list of all third-party processors in your supply chain and the personal data they process on your behalf
  • for example, keep a map of all the data flows through your supply chain
• ensure you have appropriate terms and conditions in commercial agreements, including:
  • limits on liability – you should apply these based on the sensitivity of the data
  • onward sharing of data with other sub-processors – this should be subject to the same data protection obligations as set out in the original contract with the controller

• follow government guidance on overseas hosting, multi-region cloud and software-as-a-service (SaaS) products

• perform regular audits of the third-party processor’s security controls and ensure they correspond to the controls present on the data at source

• data anonymisation, pseudonymisation and minimisation – as described in Principle 2

• separation of duties and the principle of least privilege – as described in Principle 6

• ensure employees at third-party processors have the necessary skills, competency and appropriate clearance to safely and securely handle personal data – see Principle 10

For more guidance refer to:

• Government Cloud First policy
• Multi-region cloud and software-as-a-serviceÌý
• Ìý

4. Process all personal data lawfully and ethically

You must protect the privacy of data subjects and their personal data. Not meeting your legal obligations undermines public trust, and can result in regulator sanctions, fines and loss of reputation.

You should aim to process all personal data lawfully, fairly and transparently, and comply with data protection legislation including the .Ìý

Before sharing any personal data you must establish whether you have a legal power to share data.

Controls:

• regularly review and assess your service for compliance with the

• publish a privacy notice detailing how you will process personal data

• – enforce retention policies so that personal data is only kept as long as is absolutely necessary

• carry out a full DPIA if your service requires it

Find out more about collecting personal information from users.

5. Know who owns and is accountable for your data

Every data asset in your organisation must have an owner who is accountable for that asset.

They need to ensure that the data they own is:

• fit for purpose
• of a known quality –Ìýso that its integrity is not compromised
• secure – with controls in place to protect it in transit and at rest

This helps to make faster, more responsive decisions around data.

Controls:

• follow the government’s Data Ownership Model and guidance on the Information Asset Owner (IAO) role –Ìýthey explain how personal data assets should be owned and managed

• designate and document the owners and assigned risk owners for your personal data assets, and keep these records up to date

Read out more about on the ICO website.

6. Apply appropriate data security controls

You must prevent the risk of personal data being accessed by hackers, accidentally lost, becoming corrupt or inaccurate, or not being able to access it when it’s needed.Ìý

You should aim to:

• have usable and proportionate data security controls in place to meet your risk appetite and protect personal data
• minimise the potential threats and vulnerabilities to personal dataÌý
• have accurate personal data that’s available when needed

Controls:

• perform regular IT health checks (ITHCs) or penetration tests of services

• for critical services, perform periodic assessments using the

• log and audit all data access activities

• proactively monitor activity on your services to detect cyber security events when they occur

• encrypt data in transit
  • for example, for HTTP connections use TLS 1.3
• encrypt data at rest
  • usually this will be ‘transparent encryption’, meaning the data management tools will transparently decrypt the data
  • for the most sensitive personal data, consider a second level of encryption applied at the application layer so personal data is never visible in the clear
• define and enforce access controls
  • ideally use fine-grained, attribute-based access controls (ABAC) that can act on the risk-relevant characteristics of the data (resource), the user (subject), the action and the environment
• apply separation of duties
  • for example, engineers tasked with maintaining infrastructure of a service should not routinely have access to the data stored in that service
• apply the principle of least privilege
  • only grant access to the data that a person actually needs to do their job –Ìýif they need greater access, this should be granted for a limited time with a clear justification
• ensure you have robust disaster recovery (DR) and backup processes
  • make sure you test your DR plans regularly so that you can recover data securely and safely in the event of failure

For more guidance refer to:

7. Enhance privacy controls when combining data from different sources

Data analysts working with government data sets may want to join data about individuals across different domains to draw insights from the combined data.

This needs to happen without risks to confidentiality. Vulnerable or at-risk individuals might become identifiable when multiple anonymised or pseudonymised data sources are combined.

You should ensure that data can be joined safely and securely, while allowing the value of combined data to be fully realised.

Controls:

• perform enhanced threat modelling when linking data sets, taking account of the increased risk when combining sources of personal data
  • identify the risks to personal data for each combination of data sets, noting that even when data sets have been pseudonymised, combinations of certain attributes could lead to reidentification
  • quantify the likelihood and impact of each risk
  • propose mitigations for each risk
• use before linking data
  • for example, anonymise or pseudonymise data sets before joining them, and never join identifiable data sets unless you have a clear need to

• carry out an additional DPIA for the combined data set if necessary

• ensure you have the necessary legal gateway to enable you to do the data linkage

• check that existing data sharing agreements permit the data linkage, and if not seek approval from all data asset owners
  • data sharing agreements should specify what types of linkage a recipient is allowed to make, or governance should be in place to manage risks from novel data linkages on an ongoing basis

• perform regular data flow mapping of data sets used in linkage, prevent unnecessary flows, and manage them through a secure channel

• define and enforce access controls to combined data sets, reflecting the increased risks
  • note that the risk-relevant characteristics of the combined data set will differ from those of the original data sets
• apply increased layers of encryption to the combined data set if necessary
  • for example, homomorphic, symmetric or asymmetric encryption or other hashing techniques

8. Match data using appropriate personal identifiers

Hackers can use well-known identifiers – like National Insurance numbers or NHS numbers –Ìýto track individuals across data sets.

There’s also a risk, if an organisation’s internal identifiers are leaked, of incurring a high cost to replace these identifiers across multiple data sets.

You should:

• aim to reduce the use of common identifiers across data sets for the purposes of matching
• be able to manage how the identifiers in your organisation’s data sets are used outside of your organisation

Controls:

• keep identifiers used for matching separate to those used routinely

• require consumers of data you share to seek permission from you before using identifiers to match the data

• use , where appropriate, to reduce the impact of a data breach

  • this is when each organisation you share data with receives different but stable identifiers, meaning identifiers cannot be correlated between organisations

9. Treat vulnerable or at-risk individuals inclusively

Vulnerable or at-risk individuals must:

• be able to receive the same level of service as everyone else
• be protected in the event of a personal data breach

Controls:

• by default, make sure your service can be used by vulnerable and at-risk individuals in the same way as for the rest of the population, without requiring special arrangements

• do not identify vulnerable or at-risk groups directly in the data set used by your service – instead store this information and the nature of the risk or vulnerability separately, and limit the visibility to those with a need to know
  • for example, a separate reference data set with restricted access could list the identifiers of personal records in the main service’s data set that are for vulnerable or at-risk individuals
• hold less specific information for vulnerable or at-risk individuals in the data set used by your service, with more specific information being separated into an independent system
  • for example, for someone that works in an animal testing lab whose job may put them at increased risk, record them as a ‘research scientist’ in the main system, and separate their full employment details into an independent system
• provide the ability to securely monitor and audit access to the records for vulnerable or at-risk individuals
  • for example, by publishing record access events from the main service, a secure independent system could subscribe to these so it can alert when a vulnerable or at-risk individual’s records have been accessed
• consider vulnerable or at-risk individuals when assessing proposals to acquire, combine or share data sets, and apply these principles

10. Make sure your team has the necessary skills, competency and appropriate clearance to safely and securely handle personal data

If personal data is handled poorly, it may be accidentally compromised. Hackers also socially engineer access to personal data by exploiting unwitting insiders.

You should aim to:

• raise the general awareness and understanding of people working on your service about the risks to personal data and how to mitigate them
• have confidence that all members of your team are competent and cleared to handle personal data safely and securelyÌý

Controls:

• monitor the impact and uptake of information security and data protection training for all people involved in service delivery

• ensure information security training includes specific content on the heightened risks associated with personal data, specifically around vulnerable or at-risk individualsÌý

• require regular vetting and background checks for all members of your team, particularly if they have privileged access to personal data processed by your service

For more guidance refer to:

• National security vetting: clearance levels

Appendix

Data anonymisation and data pseudonymisation

is the process of turning personal data into anonymous information so that an individual is not (or is no longer) identifiable.

is the process of replacing or removing identifiers linking personal data to an individual, often by substituting reference numbers. Pseudonymised data still qualifies as personal data under data protection law, which means that relevant legal obligations still apply.

Baseline cyber security guidance

In addition to the various links already provided, there is other guidance on cyber security and risk management that you may find useful:

• Functional Standard GovS 007: Security –Ìýthis sets expectations for the security activities organisations must carry out to protect government assets

• –Ìýthis defines the cyber security outcomes organisations must meet and the assurance process they must follow, including:

  • approach – what government delivery teams and security professionals need to do to incorporate effective cyber security practices when building digital services and technical infrastructure
  • – this sets out minimum security outcomes that should be met under the appropriate for all services
  • cyber assurance process, which organisations must use to assure their critical services

Types of risk

Below is a non-exhaustive list of the types of risks and their impact which you may encounter when handling personal data in government services. The actual risks you have will be specific to your service and use case.

Loss of personal data

Risks resulting in a loss of personal data include:Ìý

• an engineer diagnosing a bug in a service exports personal data as a plain text file, which is subsequently published in a public code repository
• a case worker searches either deliberately or inadvertently for the personal details of their co-workers in their case working system
• a state-sponsored hacker gets into the network and gains permissions allowing them to download unencrypted data files containing personal data

The impact that loss of personal data can have on an individual, their associates, friends and family can include:

• inconvenience and embarrassment from loss of privacy
• material loss through fraud and identity theft, including ransom and blackmail
• mental harm from loss of anonymity, including bullying, harassment and discrimination
• physical harm or threat to life from being identified and traced by hostile actors

The impact on an organisation can include:

• reputational damage from adverse publicity leading to loss of public trust
• compensation and legal claims, and financial penalties
• compromise of operations and disruption to services

The impact on an at-risk individual can include:

• a victim of domestic abuse could be targeted if their new whereabouts is discovered by their former partner
• government staff in sensitive roles might be subject to harm or crucial work of national importance might be compromised if the link to their employment is uncovered by hostile actors
• serving judges – whose names are a matter of public record – could be targeted if other personal details, such as their home address, become known to people they previously convicted
• public figures, for example serving MPs, could be targeted if details of their family life or where they live are found out by extremists

Accuracy of personal data

Risks that affect the integrity of the personal data you process include:

• a member of the public obscures their identity when registering for a government service for reasons of privacy or perceived risk
• a disgruntled employee willfully deletes records that contain personal data in a case management service
• a lack of training for data entry staff or poor service design results in systematic errors in recorded personal information
• a fraudster registers multiple times with a government service under false identitiesÌý

Examples of the impact this can have include:

• a police investigation seeks information on a suspect from another agency, and the information shared is inaccurate leading to misidentifying individuals
• a vulnerable person is unable to access vital support services because their identity has been intentionally obscured to protect their identity
• a healthcare professional is unable to access timely information regarding a patient’s recent test results or scans owing to the personal data held for the patient being inaccurate
• a critical government service – for example, voter registration or mass vaccination – is undermined at scale following a hack that corrupts personal data records in bulk

Access to personal data

Risks relating to how easy or hard it is to access personal data include:

• a healthcare professional responding to an emergency cannot access a patient’s records due to data security controls
• a civil servant uses an AI assistant to search departmental records, and if they have over-privileged access permissions they’re able to access personal data which they should not have access to

Examples of the impact this can have include:

• a patient involved in a serious incident could suffer complications or die as a result of the first responders being unable to access their healthcare information
• a person in need of government support has their claim delayed because their case worker is restricted from seeing their full record

Sharing personal data

Risks of sharing personal data include:

• a civil servant shares data by email as a file attachment, but accidentally sends it to the wrong recipients
• a researcher requests access to pseudonymised data from 2 departments, but on joining the 2 data sets they’re able to identify vulnerable individuals in the data who should have their identities protected

Examples of the impact this can have include:

• data owners being less likely to share their data in the future following previous data breaches when sharing data
• a high profile individual with a known rare medical condition having their health records leaked due to data shared from different sources being combined – for example, pseudonymised health records and partial address records

Not sharing personal data

There are also risks and impacts around not sharing personal data, for example:

• 2 agencies hold data about an individual that if known to each other would indicate the individual presents a risk to public safety, but the threat is not picked up because the data is not shared
• safeguarding concerns around children in care are not effectively managed because data is not being shared between social services, policing and the NHS
• government staff in sensitive roles cannot use public services effectively because their data is not shared between departments