User Access Control Policy
Updated 7 October 2026
1. Introduction
1.1. The Department for Work and Pensions (DWP) User Access Control Policy is part of a suite of security policies designed to implement and manage a consistent set of security controls across DWP and its supplier base. For the purposes of this policy, the term DWP and department are used interchangeably.
1.2. Security policies considered appropriate for public viewing are published on GOV.UK at DWP procurement: security policies and standards.
1.3. Where applicable, security policies cross-reference each other so they can be confidently used together. They contain both mandatory and advisory elements, described in consistent language as set out in the terminology section below.
2. Purpose
2.1. The purpose of this policy is to protect DWP information assets by ensuring that users have the appropriate levels of access to DWP systems, services, information and resources necessary to fulfil their role and no more, in accordance with the principle of least privilege (see policy statement 5.1).
2.2. This policy ensures that DWP User Access Controls align with, and support compliance against, the Government Cyber Security Standard (GovS 007) and the NCSC Cyber Assessment Framework (CAF).
3. Scope
3.1.This policy applies to:
3.2. All DWP employees, agents, contractors, consultants, third parties, suppliers and their sub-contractors, or anyone who has access to the department’s information and information systems, referred to as users. From this point forward, this group will collectively be referred to as ‘users’ or ‘people’.
3.3. Information systems and services in programme, project and operational business areas.
3.4. Machine Identities, such as service accounts, are subject to the Machine Identities section of this policy.
3.5. This policy establishes the baseline for standard user access. Any access that grants administrative, configuration, or security-altering rights is out of scope for this document and must strictly adhere to the DWP Privileged Users Security Policy.
3.6. This policy does not replace any legal or regulatory requirements.
4. Terminology
4.1. The following terminology is used within this policy:
4.2. Access Controls – measures that ensure only approved users can access systems and data, and that their access is limited to what is necessary in their role.
4.3. Access rights – specify which systems, services, information, or resources a user is allowed to access and what actions they are permitted to perform.
4.4. Authentication – the process of verifying the identity of a user before permitting access to systems, services, information, or resources. This involves validating credentials such as passwords, biometric data, or security tokens to ensure that only authorised individuals can proceed.
4.5. Authorisation – the process of granting a user permission to access specific systems, services, information or resources, based on their verified identity and assigned role.
4.6. Machine Identities – machine-only digital accounts used by systems to automatically access and manage services.
4.7. Privileged Users – users authorised, in line with their specific job role, to perform security-relevant functions that standard users are not. This definition applies whether the privileges are held permanently as part of a role or are granted temporarily on an escalated basis.
4.8. Privilege Creep – where a user retains and accumulates access to systems associated with previous roles or responsibilities, that are no longer required for their current role.
4.9. Standard Users – users who do not meet the criteria for privileged user status.
4.10. Toxic combinations – the assignment of access rights to a single user that, when combined, create security risks or enable actions that violate security policies.
4.11. User ID – a unique identifier supplied by a user when accessing systems, services, information or resources.
5. Policy statements
5.1. Access Controls must be determined based on business need and the principle of least privilege. Users must only be provided with the minimum access rights to systems, services, information and resources that they need to fulfil their business role.
5.2. All DWP systems must utilise Role-Based Access Control (RBAC) by default, unless a formal exemption has been documented and approved by the relevant security authority. To support dynamic risk management and progression towards Zero Trust architecture, systems should implement Attribute-Based Access Control (ABAC) wherever technically feasible.
5.3. Users must be authenticated before access is granted to systems, services, information and resources, in line with SS-001 Part 1: Access and Authentication Security Standard.
5.4. Users must hold a minimum of the Baseline Personnel Security Standard (BPSS) to access DWP systems. Depending on the system’s risk profile, National Security Vetting (NSV) may also be required where system security procedures stipulate. Exemptions to this baseline may only be granted for conditional appointments in strict accordance with Cluster 3 Security Vetting Procedures.
5.5. Privileged access must be formally authorised through defined identity, authentication, and authorisation processes and must not rely solely on line manager approval in line with the DWP Privileged Users Security Policy.
User Access Control governance
5.6. User account management procedures must be implemented for user registration, modification and de-registration on all DWP information systems in line with DWP Information Management Policy.
5.7. The user account management procedures must also include processes for monitoring redundant and inactive accounts in line with SS-001 Part 1: Access and Authentication Security Standard and SS-001 Part 2: Privileged User Access Security Standard.
5.8. All additions, deletions, suspensions and modifications to user accesses must be captured in an audit log showing who took the action and when.
5.9. Users implementing the user account management procedures must be suitably trained and authorised to do so.
5.10. System specific Access Controls must be established for all information systems. Such requirements are defined in SS-001 Part 1: Access and Authentication Security Standard.
5.11. System-specific access control requirements must be reviewed at intervals defined in SS-001 Part 1: Access and Authentication Security Standard.
5.12. The DWP Privileged Users Policy applies where a user’s role requires them to have elevated access to a DWP system.
5.13. Approved enterprise identity and access management services and controls must be enforced. Deviations from this must be formally approved via a defined exception or risk acceptance process.
5.14. Access provisioning, modification, and removal must be implemented through controlled processes ensuring authorised changes are aligned to business roles and maintain full auditability.
Authorisation and authentication
5.15. Access to applications, systems, networks, services and computing devices must be restricted to authorised users.
5.16. Authorised users must be suitably trained for the access they are granted.
5.17. Access to all DWP information systems must prioritise password-less and phishing-resistant Multi-Factor Authentication (MFA) factors where technically supported, to mitigate credential theft risks.
5.18. Where an approved exception is required (for example, where legacy systems cannot support modern authentication methods), it must be formally granted in line with SS-001 Part 1: Access and Authentication Security Standard.
5.19. The generation, distribution, storage, and lifecycle management of all authentication credentials (including the prohibition of default passwords, password sharing, and arbitrary periodic expiration) must strictly comply with the technical requirements mandated in SS-001 Part 1: Access and Authentication Security Standard.
5.20. Every user account must be assigned to a single, identifiable individual whose system identity strictly corresponds with their official enrolment details. To ensure individual accountability and non-repudiation, the creation and use of shared, group, or generic user accounts is strictly prohibited.
5.21. User IDs must be unique for each user.
Access Control review and monitoring
5.22. Inactive user accounts must be automatically disabled unless prior arrangements have been made to keep them active in line with SS-001 Part 1: Access and Authentication Security Standard.
5.23. Procedures must be in place for all information systems to ensure that users’ access rights are adjusted appropriately and in a timely manner such as whenever there is a change in business need, a user changes their role, or a user leaves the organisation.
5.24. Regular reviews must be performed on all user accounts, to check for dormant accounts in line with SS-001 Part 1: Access and Authentication Security Standard.
5.25. Where a user changes role, access rights must be reviewed and adjusted to remove unneeded access and ensure only the access required for the new role remains.
5.26. While line managers must approve the initial business justification for access, secondary authorisation must be obtained from the designated Information Asset Owner (IAO) or System Owner when explicitly mandated by the target system’s access control requirements, in accordance with SS-001 Part 1: Access and Authentication Security Standard.
5.27. Privileged access requires formal authorisation in line with the DWP Privileged Users Security Policy.
5.28. Systems must log and retain events relating to breaches of this policy, further information can be found in SS-012: Protective Monitoring Security Standard and the DWP Protective Monitoring Security Policy.
5.29. Logs must be retained for a period defined by the DWP Information Management Policy and applicable business, legal, and operational requirements, with the retention decision recorded for audit purposes.
Machine Identities
5.30. Machine Identities (for example service accounts, Application Programme Interface (API)s, and bots) must only be used for approved automated or system-to-system activity.
5.31. Each Machine Identity must have a named human ‘Service Owner’ accountable for its activity and review.
5.32. Machine Identities must be recorded in an approved inventory or system access register.
5.33. Machine Identities must utilise Workload Identity Federation (token-based authentication) to access cloud resources where technically supported, eliminating the use of static credentials.
5.34. Machine Identities authentication sessions must be short-lived, scoped and revocable.
5.35. Tokens or assertions used by Machine Identities must be time-restricted, audience-restricted, integrity-protected and validated before access is granted in line with SS-001 Part 1: Access and Authentication Security Standard.
5.36. Where static secrets are unavoidable, credentials must be stored in a DWP-approved secrets management solution and rotated automatically at intervals defined by business risk, but no less frequently than the annual recertification cycle.
5.37. Machine Identities must be logged and subject to periodic access review intervals. Dormant, orphaned, no longer owned and no longer required Machine Identities must be disabled, revoked or removed within the time periods defined in SS-001 Part 1: Access and Authentication Security Standard.
5.38. Machine Identities must be granted the minimum permissions required for their approved automated function. The permissions must be scoped to the specific system, service, API, data set, environment and operation required. Broad, wildcard, standing or cross-environment permissions must not be granted unless formally risk-assessed, approved and time-bound.
5.39. Machine Identities must not be shared across production and non-production environments.
6. Accountabilities and responsibilities
6.1. The DWP Chief Security Officer is the accountable owner of the DWP User Access Control Security Policy and is responsible for its maintenance and review, through the DWP Deputy Director for Security Policy and Central Services.
Information Asset Owners
6.2. Information Asset Owners are responsible for ensuring that the requirements of this policy are implemented within any programme, projects, systems or services for which they are responsible.
Line managers
6.3. Line managers are responsible for ensuring that members of their team have the minimum levels of access to systems they need to perform their role.
6.4. Line managers must authorise the access rights for each individual team member.
6.5. Line Managers must ensure that access rights are revoked as soon as practical where employees change duties, job role or leave the organisation.
6.6. Line Managers must review the access levels of their direct reports, at least annually, to ensure they are appropriate for their job role.
7. Compliance
7.1. 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.
7.2. 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.
7.3. 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 immediately. 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).
7.4. 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, additional information can be found in the DWP Employee Privacy Notice.
7.5. The Security and Data Protection Team—acting as the DWP authority responsible for the security and operational delivery of digital services—retains the explicit right to restrict, suspend, or terminate any user’s access to departmental systems, software, and hardware at any time.
7.6. All exceptions to policy security gaps, or use of non-standard access 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)). Exception requests carrying significant enterprise or cross-border risk must be escalated to the Chief Security Officer (CSO) and relevant Security Directors for final approval prior to SRO acceptance.
7.7. Where immediate compliance with the mandatory requirements of this policy is not technically feasible (for example, due to legacy infrastructure constraints), systems may operate under a formal Transitional Arrangement. This requires the implementation of standard, Enterprise-approved compensating controls alongside a documented, risk-managed remediation roadmap. Individual risk assessment and ratification by the Digital Design Authority (DDA) or PSRG is only required where a system’s proposed compensating controls deviate from these pre-approved departmental patterns.
8. References
SS-001 Part 1: Access and Authentication Security Standard
Cluster 3 Security Vetting Procedures
DWP Privileged Users Security Policy
DWP Information Management Policy
SS-001 Part 2: Privileged User Access Security Standard
SS-012: Protective Monitoring Security Standard
DWP Protective Monitoring Security Policy
DWP Security Incident Management Standard (SS-014)
9. Version control (changes from previous published version)
| Paragraph | Changes made and reason |
|---|---|
| Whole policy | Updated the policy into the new Security Policy Template. |
| Scope | Additional updates reflecting how User Access Controls align with Government Cyber Security Standard (GovS 007) and NCSC Cyber Assessment Framework (CAF). |
| Statement 5.2 and statement 5.8 | Statements merged in order to address both RBAC and ABAC within the same statement concerning zero-trust architecture. All statements minus 1 numbering. |
| Statement 5.3 | New additional statement to cover authentication to systems, services, information and resources linking to SS-001 Part 1: Access and Authentication Security Standard. |
| Statement 5.4 | Updates the security clearance requirements when accessing DWP systems. |
| Statement 5.5 | Statement covers privileged access authentication and authorisation rather than relying solely on line manager approval. |
| Statement 5.14 | Enforcement of identity and access management and if not possible notes the requirement for a defined exception or risk acceptance. |
| Statement 5.15 | Notes the requirement for authorised changes to be aligned to business roles. |
| Statement 5.18 | Prioritises MFA for security reasons where technically supported. |
| Statement 5.19 | States the exceptions process such as for legacy systems where MFA is not applicable. |
| Statement 5.20 | Indicates the requirements for authentication mechanisms and replaces previous password-related statements (18 to 25). |
| 5.21 | Mandates that all user accounts are uniquely identifiable and available for monitoring following discussions regarding monitoring and logging. |
| 5.23 | Points the reader towards the policies and the defined timelines within. |
| 5.25 | Discusses what should occur regarding access rights when an individual moves role to stop aggregation of access rights. |
| 5.28 | This statement directs users requiring privileged access to follow the Privileged Users Security Policy. |
| Machine identity | A complete rewrite of the Machine Identities section. Introduces additional controls for automated system activity, requirements of human service owners, identity recording, Workload Identity Federation and identity lifecycle controls. This strengthens the security for the use of machine identities within the department. |
| Compliance | Included a new statement which provides Security and Data Protection Team the ability to restrict, suspend or terminate user access to systems, software and hardware. |