Guidance

Privileged Users Security policy

Updated 21 May 2026

This DWP Privileged Users 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 regard 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	should denotes a recommendation: an advisory element.
may	denotes approval.
might	denotes a possibility.
can	denotes both capability and possibility.
is/are	is/are denotes a description.

Overview

The DWP Privileged Users Security Policy sets out privileged user access and use of DWP systems in line with DWP’s relevant security policies.

Purpose

This policy is to outline privileged users access within DWP ensuring that is it managed securely, minimising the risk of unauthorised access, data breaches and insider threats. The policy establishes mandatory controls and governance aligning with UK Government Standards, DWP security requirements and international best practices.

Scope

This policy applies to:

a) DWP employees (including contractors, consultants and other workers) who from this point forward will collectively be referred to as ‘users’.

b) All contracted third-party 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 confidentiality, integrity and availability of the departments assets, including data assets.

c) All privileged entities, including:

• Human Users: Employees, contractors and third parties with elevated rights

• Non-Human Identities (NHI): Service accounts, robotic process automation (RPA), bots, and API keys that hold elevated privileges (as defined in SS-001-2: Privileged User Access)

• AI Systems: Identities with access to modify Artificial Intelligence (AI) training data, model weights, or inference pipelines.

d) This policy applies to all Cloud (SaaS, PaaS, IaaS) and On-Premises environments.

e) This policy does not replace any legal or regulatory requirements.

Definitions

Privileged User / Entity

A user that is authorised, in accordance with their specific job role, to perform security-relevant functions that standard users are not. Such functions require a higher level of trust and may include, but are not limited to, managing security configurations, altering system operation and administering other user accounts. This definition applies whether the privileges are held permanently or are granted on a temporary or time limited basis.

Privileged Access Workstations (PAWs)

A highly secured, hardened, and isolated physical or virtual device designed for administrators handling high-risk tasks, such as managing servers, cloud services, or sensitive data. PAWs restrict daily, high-risk activities—like email and browsing—to prevent malware infection, credential theft, and unauthorized access to critical infrastructure.

Privilege criticality is determined by the impact of the asset managed, rather than the job title. This includes:

• Tier 0 - (Root of Trust): Control over enterprise identity (for example Active Directory, Cloud Root, PKI) or Critical National Infrastructure (CNI). Compromise here allows control over the entire organisation;
• Tier 1 - (Critical Infrastructure): Control over critical business data, applications, and cloud services. Compromise causes widespread disruption;
• Tier 2 - (Support Infrastructure): Administration of specific business support applications or web servers. Compromise is limited to specific components;
• Tier 3 - (Constrained): Constrained functions (for example First Line Support and password resets) with limited impact.

DWP’s privilege tiering aligns with NCSC guidance on Secure System Administration and applied to all privileged roles. The tiers reflect the potential impact of compromise. PAWs are an additional control required only for higher risk Tier 0 and Tier 1 activities.

Policy Statements

1. Privileged user access decisions must be administered through approved access controls which dynamically check the user’s identity, context, and access requirements. The technical enforcement of these controls (such as Zero Trust and Attribute-Based Access Control) must be implemented exactly as defined in SS-001-2: Privileged User Access.
2. Users with lower levels of access (such as Tier 3) must not be able to modify or reset credentials for accounts with higher levels of access.
3. High-risk administrative work must be performed through Privileged Access Workstations (PAWs) which a must be used for all Tier 0 and Tier 1 administrative activities. PAWs must be physically or logically separated from standard productivity tasks. For Tier 2 and 3 activities, secure intermediaries (for example Bastion/Jump Hosts) must be used in line with SS-001-2: Privileged User Access.
4. Privileged access must only be provided for business needs and be timebound, being granted through a documented approvals process. Emergency access must also be justified, approved and time limited.
5. Permanent privileged access must be avoided where possible. Access should only be granted when it is required for a specific task and removed when no longer required line with SS-001-2: Privileged User Access.
6. There must be a formal authorisation process to grant, assign and approve the allocation of a privileged user role.
7. Passwords, keys and additional credential information for privileged accounts must be stored in an approved secure system (SS-001-2: Privileged User Access.)
8. Privileged account credentials must be strong, system generated where applicable and changed regularly (SS-001-1: Access and Authentication Controls).
9. Privileged accounts must use strong multi-factor authentication. The second factor must be kept separate from the main device being used. Any exception to this must be formally approved and supported by additional security measures in line with SS-001-1: Access and Authorisation Controls and SS-001-2: Privileged User Access.
10. Requests to recover a privilege account or resetting credentials must be validated through a trusted second method verification such as multi-factor authentication or video verification with a line manager. Personal security questions (for example memorable dates, pet names) must not be used.
11. Privileged accounts must use strong multi-factor authentication. The specific technical requirements for this, including the mandate for mechanisms deployed with significant phishing resistance, are defined in SS-001-2: Privileged User Access.
12. All privileged users must hold the appropriate, valid security clearance (e.g., SC or DV) mandated for the specific role and assets they are assigned to, prior to being granted privileged access. Privileged users must adhere to the personnel security requirements within the Personnel Security Policy and the DWP Security Vetting Procedures.
13. Privileged user access must only be granted to permanent DWP employee or to permanent employee/contractors that have a formal contractual agreement with DWP, including commitments to NDAs and maintaining DWP information security standards.
14. All privileged users must be uniquely identifiable and linked to a user, system or approved role.
15. All privileged users must be managed through DWP’s approved identity and access management processes.
16. Privileged access must be managed throughout its lifecycle with access being removed when no longer required such as a member of staff leaving post or when the account is dormant.
17. Joiners, Movers and Leavers (Joiners, Movers & Leavers Policy) processes must include privileged access. Access should be granted and revoked automatically (SS-001-2: Privileged User Access). If automation cannot be achieved an approved exception must be sought. This also applies to non-human privileged accounts.
18. Requests to undertake critical IT administrative actions via remote communication channels (for example, phone, video) must be validated using a separate trusted verification channel, as voice and video alone are vulnerable to AI-generated deepfakes. The technical requirements for this, along with specific exemptions for routine Tier 2 and Tier 3 frontline customer verification, are mandated in SS-001-2: Privileged User Access.
19. Privileged user access rights must be reviewed regularly, confirming if there is still a requirement in line with SS-001-2: Privileged User Access.
20. Any changes for privilege access must be approved through a change process, and he request verified before being undertook.
21. A record of all privileged user roles assigned, and their level of access must be recorded, maintained and made available on request.
22. Privileged user account, and activities must be logged, monitored, retained and reviewed in line with SS-012: Protective Monitoring.
23. Privileged accounts must only be used for tasks that require elevated privileged and not for routine business activity.
24. Privileged accounts must be disabled when they are inactive, don’t have a clear owner and do not meet policy requirements.
25. Security training for privileged users must be defined, owned and monitored by the appropriate business or functional authority, including arrangements covering contractors where applicable.
26. Users with privileged access must sign additional agreements accepting responsibility for the use of privileges and be issued role-specific procedures.
27. Business continuity and disaster recovery plans must explain how privilege accesses will be provided, controlled and managed through disruption or recovery.
28. When older systems cannot support modern privilege controls additional security controls must be put in place in compliance with SS-001-2: Privileged User Access.
29. Activities perform on privilege user accounts must not be performed through generic or shared privileged accounts. Where this cannot be achieved it must be risk assessed, authorised by Senior Responsible Officer (SRO), monitored and audited in line with SS-001-2: Privileged User Access.
30. All contractors requiring privileged user access must be accountable to and have their access managed by a DWP permanent member of staff responsible for reviewing access and approving any change requests.
31. Non-Human Identities (NHI) (for example, service accounts) must be managed with the same rigour as human privileged accounts. The technical mechanisms to achieve this, including the mandatory use of Workload Identity Federation to replace static secrets where supported, are defined in SS-001-2: Privileged User Access.
32. Where privileges enable access to, administration of, migration of, transformation of or obfuscation of sensitive DWP data, the activity must comply with the DWP Data Obfuscation Security Policy.

Accountabilities and Responsibilities

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

b) Privileged user access must be requested in writing, detailing the access required, and authorised by a SRO. A record of all privileges allocated must be maintained by the SRO.

c) Privileged user access for a supplier must be requested in writing, detailing the access required, and authorised by the applicable Authority (equivalent to the SRO role) for that supplier.

d) A record of all privileges allocated must be maintained by the Supplier Security Manager.

e) Suppliers must inform the Authority if any access has had to be revoked as a consequence of a security incident.

f) Suppliers must be able to provide the Authority with audit logs or records that show when the privileged accounts have been used upon request.

g) 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 PSRG) prior to Senior Responsible Owner (SRO) acceptance.

Compliance

a) All users, 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. DWP users must report security incidents via the DWP Security Incident Referral Webform; third parties and 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 controls such as filtering and monitoring tools to protect DWP computer and electronic communication systems by preventing unauthorised access and distribution of malicious software. Where the controls involve the monitoring or logging of user activity and the processing of personal staff data, this activity is carried out inline with the DWP Employee Privacy Notice which explains what data is collected, how it is used and the safeguards in place.

e) An exception to policy may be requested in instances where a business case can be made to undertake an activity that is non-compliant with DWP’s Security Policies. This helps to reduce the risk of non-compliant activity and security incidents. 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 PSRG) prior to Senior Responsible Owner (SRO) acceptance. If an individual is aware of an activity that falls into this category, they should notify the Security Policy and Standards Team immediately.