Guidance

Data Obfuscation Security Policy

Updated 11 June 2026

This DWP Obfuscation Security Policy is part of a suite of policies designed to promote consistency across the Department for Work and Pensions (DWP) and supplier base with regards to the implementation and management of security controls. For the purposes of this policy, the term DWP and Department are used interchangeably.  

Security policies considered appropriate for public viewing are published on GOV.UK 

Security policies cross-refer to each other where needed, so can be confidently used together. They contain both mandatory and advisory elements, described in consistent language (see table below).

Term	Intention
must	denotes a requirement: a mandatory element
should	denotes a recommendation: an advisory element
may	denotes approval
might	denotes a possibility
can	denotes both capability and possibility
is/are	denotes a description

Overview 

1. The DWP Data Obfuscation Security Policy outlines the enterprise level requirements for how data must be obfuscated or transformed to protect sensitive information across the Department.

Purpose 

2. This policy is to mandate the high-level requirements for the type and degree of data transformation required based on data sensitivity, processing environment, and intended use, ensuring residual data risk remains within the Department’s acceptable tolerance. This policy supersedes the 2019 DWP Data and Analytics Data Obfuscation Policy. 

Scope 

1. This policy applies to: 

(a) All DWP personnel (including employees, contractors, and temporary staff) involved in the design, development, processing or management of DWP data transformation and obfuscation processes. 

(b) All contracted suppliers whose systems or services store, handle, or process DWP information, or are involved in the provision and lifecycle management of hardware for the DWP; to ensure the appropriate levels of assurance for the confidentiality, integrity and availability of the DWP’s assets.

(c) All DWP data assets including those managed by suppliers, across all environments (on-premise, hybrid, and cloud) and in all states (at-rest, in-motion, in-use). 

(d) Personnel assigned to roles with privileged access to sensitive data assets, including those managed by suppliers or hosted offshore, must hold the appropriate level of security clearance as defined by the DWP Vetting Policy for that specific assigned role.

2. This policy does not replace any legal or regulatory requirements.

Definitions 

Acceptable Tolerance 

The level of residual re-identification risk a Data Owner is willing to accept, as documented in a Data Protection Impact Assessment (DPIA) and approved by the Information Asset Owner (IAO). 

Artificial Intelligence

A computer programme which “learns” from data and may perform tasks usually carried out by humans. 

Anonymisation 

Anonymisation is a process that renders individuals not identifiable by any means reasonably likely to be used, thereby residing outside the scope of data protection law. 

Data Minimisation 

The principle of collecting, processing and storing the minimum amount of personal data required to fulfil a defined purpose.

Data Masking 

Replacing sensitive data with fictional or scrambled values while preserving the data’s format. Common examples include replacing names with pseudonyms or masking credit card numbers. 

Encryption / Tokenisation

The process of converting information or data into a code, especially to prevent unauthorised access. 

Infrastructure as a Service

A cloud model delivering virtualized computing resources – such as servers, storage, and networking – over the internet. 

Irreversible Masking

A one-way substitution of data which can no longer be reinstated to its original form. 

Mandatory Transformation Tier

The structured, mandatory processes of modifying raw data to meet legal, security or privacy requirements. 

Motivated Intruder Test 

A re-identification risk assessment method identified within the Information Commissioner’s Office (ICO) Anonymisation Code of Practice to determine if a person without prior knowledge could identify an individual from an anonymised data asset, considering all means reasonably likely to be used. 

Obfuscation

A collective term for technical measures (for example masking, pseudonymisation, aggregation, anonymisation, tokenisation, encryption) that reduce the risk of identifying individuals from data. Obfuscation does not in itself remove data from the scope of data protection law unless the outcome meets the standard for anonymisation. 

Platform as a Service

A cloud model where the provider manages the underlying infrastructure, allowing customers to build, deploy, and manage applications without maintaining servers or operating systems. 

Production Derived Data Assets

Specialised data assets generated by applying transformations, aggregations, or calculations to raw, primary, or operational “source-of-truth” data within a production environment. 

Pseudonymisation

The processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is subject to technical and organisational measures to keep it separate.

Record of Processing Activities (ROPA)

A formal record which documents how an organisation processes personal data, describing the purpose of processing, categories of personal data and data subjects, lawful basis for processing, data sharing arrangements, retention period and the technical and organisational security measures applied.  

Software as a Service

A cloud service model where the provider runs an application shared between customers, who then configure and consume it, opposed to managing the underlying infrastructure. 

Suppliers

Any external organisation or individual providing services, systems, or hardware to the Department under a formal agreement, including contractors and service providers.

User Acceptance Testing

A critical, final phase of assurance where end-users validate that a system or service meets their needs, functions as expected in real-world scenarios and operates within defined risk appetites prior to going live. 

Policy Statements 

1. The principle of Data Minimisation must be applied to all data assets prior to transformation or usage.  

2. All requests for access or migration of Production Derived Data Assets (PDDs) must specify the Mandatory Transformation Tier required to satisfy this policy, as mandated by the relevant Data Owner.

3. The selection of the Mandatory Transformation Tier must be documented by the Data Owner, identifying which of the four protection levels (Encryption, Pseudonymisation, Irreversible Masking, or Anonymisation) is required for the specific use case. 

4. Initiatives which involve transformation activities relating to personal data must follow the Data Protection Impact Assessment (DPIA) process and where transformation activities affect the identifiability comply with the Motivated Intruder Test. The required execution and evaluation criteria for this test will be proportionate to the identified risk and defined in DWP obfuscation procedures. 

5. Data protection for operational systems, including Critical National Infrastructure (CNI) systems hosted in the Cloud must be primarily secured via strong access controls and encryption, in line with the DWP Cryptographic Key Management Policy and SS-007: Use of Cryptography. 

6. For non-production cloud environments (Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS)), encryption at rest (SS-007: Use of Cryptography) is a mandatory baseline but must not be used as a substitute for irreversible masking. Non-production environments are strictly prohibited from containing unmasked sensitive production data. 

7. Where a documented business requirement for individual identification exists (for example for social research sampling or fraud targeting), data assets may be exempt from the Irreversible Masking mandate if hosted within a Protected Analytical Environment. These environments must implement production-equivalent security controls, including granular Role-Based Access Control (RBAC) and comprehensive auditing. 

8. Where a business requirement exists to perform individual identification or selection within a secondary environment (for example for cohort targeting), the data must be hosted in a Protected Analytical Environment. These environments are not subject to obfuscation mandates but must implement production-equivalent controls, including strict RBAC, full auditing, and adherence to the record indistinguishability manual. 

9. Policy implementation must ensure that data transformation maintains sufficient utility for analytical modelling and social research (for example preserving event ordering and precision for business-critical variables), provided re-identification risk remains within tolerance.

10. Any display-level (dynamic) masking used within operational user interfaces (for example to confirm bank details) must be implemented at the application tier and must not alter the underlying data at rest. 

11. Irreversible Masking must be performed on all highly sensitive personal data prior to copying, migration, or provisioning into any non-production, development, or User Acceptance Test (UAT) environment. 

12. Protection must be applied to Artificial Intelligence (AI) and machine learning training pipelines to prevent accidental data exposure via membership inference or model outputs. 

13. Non-production Database Management Systems (DBMS) must implement technical ingress controls (for example pre-restore triggers) to prohibit the restoration or importing of unmasked production data, in compliance with SS-005: Database Management System. 

14. Data used for statistical publication or shared with external research bodies must achieve a verified level of anonymisation (for example K-Anonymity, Differential privacy) to prevent re-identification and reconstitution attacks. The Department must ensure that no form of differential data masking or obfuscation applied to data in operational services compromises the requirement for sensitive records to remain indistinguishable.

15. Where pseudonymisation is required to maintain data linkage in analytical platforms, the method must adhere to the cryptographic hashing, salting (“Pepper”), secure key management requirements defined in supporting DWP technical products, standards, and patterns. Additional information must be logically and physically separated with access strictly limited. 

16. Where privilege access is required to administer, transform, migrate, restore or manage sensitive data assets this must comply with DWP Privileged Users Security Policy and SS-001-2: Privileged User Access.

Accountabilities and Responsibilities 

(a) The DWP Chief Security Officer is the accountable owner of the DWP Obfuscation Security Policy and is responsible for its maintenance and review, through the DWP Deputy Director for Security Policy and Central Services. 

(b) The Data Owner is accountable for the anonymised / pseudonymised outcome for each data asset, ensuring the lawful basis, purpose limitation and data minimisation principles are applied and documented, and accepts any residual re‑identification risk within the DPIA / Record of Processing Activities (ROPA) before authorising onward use or disclosure. 

(c) The Information Asset Owner (or equivalent role as defined by the Chief Data  Office) is accountable for the information asset’s management and protection, maintaining the Information Asset Inventory (also referred to in security standards as the Information Asset Register or IAR), setting and monitoring access, sharing, retention and disposal controls, and providing assurance that controls are appropriate and proportionate.

(d) Product / System Owner is responsible for implementing and enforcing the approved outcomes by encryption and other controls for obfuscated data. 

(e) Suppliers that cannot comply with the security policy must request a security policy exception. All exceptions, security gaps, or use of non-standard access (such as generic accounts) must be risk-assessed and ratified by the appropriate formal governance board (for example, the Digital Design Authority or Policy and Standards Review Group (PSRG)) prior to Senior Responsible Owner (SRO) acceptance. 

Compliance

(a) All DWP employees, whether permanent or temporary (including DWP’s contractors) have security responsibilities and must be aware of, and comply with, DWP’s security policies and standards.  

(b) Many of DWP’s employees and contractors handle sensitive information daily and so need to be enacting minimum baseline behaviours appropriate to the sensitivity of the information. Most security incidents and breaches relate to information security.

(c) Failure to report a security incident, potential or otherwise, could result in disciplinary action and, in the most severe circumstances, result in dismissal. A security incident is the attempted or actual unauthorised access, use, disclosure, modification, loss or destruction of a DWP asset (or a supplier asset that provides a service to the Authority) in violation of security policy. The circumstances may include actions that were actual, suspected, accidental, deliberate, or attempted. Security incidents must be reported as soon as possible. Suppliers must follow the DWP Security Incident Management Standard (SS-014).

(d) DWP’s Security and Data Protection Team will regularly assess for compliance with this policy and may need to inspect physical locations, technology systems, design and processes and speak to people to facilitate this. All DWP employees, agents, contractors, consultants, business partners and service providers will be required to facilitate, support, and when necessary, participate in any such inspection. DWP Collaboration and Communication Services will use software filters to block access to some online websites and services.

(e) Any exemption to this policy must be formally risk-assessed and approved by the appropriate governance board (for example the Digital Design Authority (DDA) or PSRG), rather than solely by the project Senior Responsible Owner (SRO). If an individual is aware of an activity that falls into this category, they should notify the Security Policy and Standards Team immediately.