Guidance

Technical Vulnerability and Continuous Threat Exposure Management Security Policy

Updated 7 October 2026

1. Introduction

1.1. The Department for Work and Pensions (DWP) Technical Vulnerability and Continuous Threat Exposure Management Security Policy is part of a suite of security policies designed to implement and manage a consistent set of security controls across the Authority and its supplier base.

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 primary objective is to move beyond “patching at scale” to “exposure management at pace”. This policy ensures the Authority and all contracted third-party suppliers have a documented, approved process for the identification, validation, prioritisation, and automated response to exposures that pose a contextual risk to the Authority.

3. Scope

3.1. This policy applies to the Authority’s employees (including contractors, consultants and other workers) involved in the provision and lifecycle management of hardware and software for the Authority. It also applies to all contracted third-party suppliers whose systems or services store, handle, or process the Authority’s information. From this point forward, this group will collectively be referred to as ‘users’ or ‘people’.

3.2. Business-Led Scoping: discovery and remediation efforts must be directed toward Business-Led Scopes aligned with senior leadership priorities rather than relying solely on technical identifiers (for example IP ranges or subnets). Scopes must be defined by: 

• business impact: revenue-driving applications, citizen-facing services, and critical welfare payment systems

• business-driven Events: systems supporting major technology changes, acquisitions, or high-visibility projects

• accessibility: publicly exposed enterprise IT subscriptions (Software as a Service (SaaS)), supply chain dependencies, and external-facing edge infrastructure.

3.3. This policy covers the Authority’s requirements for identifying and remediating technical vulnerabilities across Information Technology (IT) infrastructure, operating systems, applications, cloud-native platforms, and network appliances throughout all stages of the services lifecycle. 

3.4. When procuring new software, systems, or third-party services, Authority teams should rigorously consider the provider’s vulnerability management practices, security support commitments, and patching capabilities as part of the risk assessment process to ensure they are resilient against artificial intelligence (AI)-accelerated threat discovery and exploitation.

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

4. Terminology

4.1. The following terminology is used within this policy:

• “must” is used to denote a mandatory requirement that always needs to be complied with
• “should” is used to denote elements that are expected to be implemented where possible but are not strictly mandatory
• “may” and “could” are used for elements that are optional or desirable

5. Definitions

5.1. Security Patches: any fix that remediates a security vulnerability within the system.

5.2. Continuous Threat Exposure Management (CTEM): a dynamic framework that expands beyond technical flaws to evaluate the visibility, accessibility, and vulnerability of digital assets.

5.3. Contextual Risk: The level of risk a vulnerability poses considering factors specific to the Authority’s environment, including the asset’s role, data.

5.4. Operational Security Domains: a 4-dimensional risk model comprising Environment (Development to Production), Business Value (Criticality Levels 1 to 4), Resilience (Maturity Levels 1 to 6), and Exposure (Low to Critical) used to contextualise an asset’s true risk.

6. Policy statements

Consistent with the ‘mitigate-first’ and ‘update by default’ principles, security measures must be applied as soon as possible. The Authority’s Digital Function, Product Delivery Units and contracted parties must ensure people and processes are in place to meet these objectives.

Identification and discovery

6.1. Potential vulnerabilities across the Authority’s digital assets must be identified through CTEM and automated telemetry, rather than relying solely on static, point-in-time scanning. To validate this continuous baseline, independent external assurance must be undertaken in strict accordance with the DWP SS-027: Security Testing Standard. All Authority digital asset exposure must remain visible to the Cyber Resilience Centre (CRC) in near real-time.

6.2. A comprehensive and continuously maintained asset inventory of all hardware, software, firmware, and service assets must be established. This must include patch status, version currency, and lifecycle state for all assets, including identification of unsupported, deprecated, or dormant systems capable of re-deployment. In mature environments, this must include Software Bill of Materials (SBOM), Identity and Access Data, and Firewall Rule Analysis.

6.3. Scan Frequency:

• Externally Facing/Edge Assets: to close critical visibility gaps, all internet-facing assets and critical edge infrastructure must undergo continuous vulnerability scanning and telemetry monitoring to detect exposure to rapidly emerging threats.

• Internal Infrastructure: must undergo authenticated security scanning at a minimum weekly interval. With an absolute Authority mandate to transition to continuous, automated scanning architectures.

• Attack Surface Reduction: the Authority must continuously evaluate its external attack surface, aggressively decommissioning non-essential internet-facing systems to reduce overall exposure.

6.4. In-use vendors must be proactively monitored for security announcements and advisories, and it must be determined whether software code that can exploit a new vulnerability (zero-day exploit) is publicly available.

6.5. The Authority must continuously collect, review, and act upon threat intelligence to actively inform the discovery and validation phases. This must incorporate external threat intelligence feeds, alongside internal analysis from departmental threat intelligence functions.

6.6. Indicators of Compromise (IOCs) must be continuously captured, logged, and enriched within departmental platforms with resulting threat assessments and proactive network blocking directives disseminated rapidly via established IT service management workflows to orchestrate validation and response.

Classification and risk evaluation

6.7. Vulnerabilities must be analysed beyond technical severity (for example Common Vulnerability Scoring System (CVSS)) to assess their potential impact, Contextual Risk and exploitability within the Authority’s environment, and their contribution to any toxic combinations of risks.

6.8. All prioritised risks must be evaluated against the Operational Security Domains (Environment, Value, Resilience, Exposure) to determine the appropriate response tier.

6.9. Validation Formula: A triage must assess exposures using the formula: Validation = Impact x Viability. Impact represents the potential attack path to a critical business asset, and Viability is the technical success of a compromise verified through Adversarial Exposure Validation (AEV) or simulation.

6.10. All vulnerability remediation decisions must be supported by a documented, risk-based assessment. This assessment must consider exploitability, operational impact, compensating controls, and business criticality. Decisions to apply, defer, or modify remediation actions must be recorded and retained for audit and assurance purposes.

Prioritisation

6.11. All entities must implement a documented, risk-based methodology for prioritising vulnerability remediation.

6.12. This prioritisation methodology must incorporate Exploitability (For example: the CISA Known Exploited Vulnerabilities Catalogue), Potential Impact, Exposure, Severity (using Threat Intelligence Risk Scores), and Compensating Controls.

6.13. Target Profile - Edge Infrastructure:

• Exceptional prioritisation must be assigned to vulnerabilities affecting enterprise edge infrastructure (for example, VPN gateways, Firewalls, Load Balancers).

• Following National Cyber Security Centre (NCSC) network security fundamentals, continuous validation must verify the strict logical and physical isolation of the device management plane from the data routing plane.

• Management interfaces must never be exposed to untrusted external networks and must be restricted to highly authenticated, out-of-band administration channels utilising robust access controls (for example, Multi-Factor Authentication (MFA), Privileged Access Management (PAM), IP/Geo allow-listing, or dedicated management Virtual Local Area Networks (VLANs)).

Response: Mitigation (Primary Response)

Due to the increasing prevalence of Zero-Day exploits and negative Time-to-Exploit trends, Mitigation is the primary immediate response mechanism.

6.14. ‘Mitigate-First’ Protocol: upon the prioritised identification of a high-impact exposure, compensating controls (for example, virtual patching, Web Application Firewall rules, service isolation) must be deployed immediately to neutralise the attack path, preceding permanent software remediation. The mitigations must be time-bound, continuously monitored, and must not be treated as a permanent substitute for remediation.

6.15. Automated Response (Act Now): In mature cloud environments, authority is granted for automated risk reduction (for example, automated shutdown, CI/CD pipeline remediation) upon detection of a critical exposure to prevent a security incident.

6.16. Pre-Patch Response Protocol: The Emergency Response Plan empowers the immediate execution of defensive actions prior to the availability of vendor-supplied patches. Upon receipt of high-confidence threat intelligence indicating active exploitation in the wild, Proactive Cyber Operations hold the authority to implement immediate containment measures (for example, port blocking) based on intelligence alone.

6.17. Post-Exposure Investigation: Where a critical exposure is identified that is subject to active exploitation in the wild, and an exposure window existed prior to mitigation, the Risk Owner must evaluate the threshold for invoking formal Cyber Incident Response (CIR) procedures (aligned with DWP SS-014: Security Incident Management Standard) to investigate potential compromise.

Response: Remediation (Permanent Resolution)

6.18. Following immediate mitigation, a permanent remediation action (for example, patching, upgrading, or decommissioning) must be applied. Mitigations must be time-bound, continuously monitored, and must not be treated as a permanent substitute for remediation.

6.19. Vulnerability remediation actions must undergo a documented, risk-based assessment evaluating the impact of applying or deferring updates. Decisions must consider exploitability, operational impact, compensating controls, and business criticality, and must be recorded and retained for audit.

6.20. Technical vulnerabilities identified through CTEM activities must be prioritised and addressed in accordance with the mandatory timescales defined in DWP SS-033: Patching and Exposure Management Standard. This includes adhering to the specified timescales for both immediate tactical mitigation (the application of robust compensating controls) and permanent remediation (patching).

6.21. Security weaknesses identified through independent external assurance activities, must be assessed, tracked, and addressed in accordance with DWP SS-027: Security Testing Standard.

6.22. Patch deployment, configuration management, and mitigation enforcement must be automated to the greatest extent possible to meet threat-driven timelines.

6.23. Immutable infrastructure must be kept up to date continuously via updates to defined minimum frequencies, achieving the same purpose as patching.

6.24. Updates must be classified to distinguish between security patches, configuration changes, and functional updates. Only updates that remediate security vulnerabilities fall within the scope of this policy.

6.25. Security patches and remediation actions must be tested in a representative environment prior to deployment. Where testing cannot be completed due to urgency, a risk-based decision must be recorded and compensating controls applied.

6.26. Explicit Service Level Agreements (SLAs) must be mandated contractually with third-party providers for timely vulnerability remediation.

Proportionate Requirements for Suppliers and Legacy Estates

6.27. The Authority recognises that not all third-party suppliers or legacy environments currently possess the advanced tooling required to continuously and automatically prove their security controls are working (a concept referred to internally as Automated Control Attestation to Risk). In alignment with ISO/IEC 27002:2022 Control 5.20 (Supplier Agreements), where advanced automated responses are technically unfeasible, suppliers and legacy asset owners must implement compensatory measures.

6.28. Manual Posture Attestation: Suppliers operating outside the automated CTEM framework must provide regular, documented reporting verifying their security posture against the Authority’s established Operational Security Domains (as defined in section 4). This includes explicitly mapping the assets: Environment, Value (Levels 1 to 4), Resilience (Levels 1 to 6), and Exposure levels.

6.29. Suppliers operating outside the automated CTEM framework must provide regular, documented reporting that demonstrates their security posture in line with the Authority’s expectations. This includes mapping relevant assets and services in terms of operating environment, business value, resilience characteristics, and exposure, aligned to the principles set out within this policy and related security standards.

6.30. Legacy Compliance: while mature environments transition to compressed timescales, legacy environments and external suppliers unable to meet these automated timelines must comply with the requirements and remediation timescales specified in DWP SS-033: Patching and Exposure Management Standard.

6.31. Unpatchable Systems: where patching or remediation timelines cannot be met the associated risk must be formally accepted, time-bound, and subject to enhanced monitoring. Systems operating below supported versions must be treated as lifecycle risks and prioritised for remediation or decommissioning.

Acceptance

6.32. Formal, time-bound Risk Acceptance by the Authority’s Accountable Senior Responsible Officer (SRO) is required when residual risks cannot be adequately remediated or mitigated further. Where remediation cannot be completed within the required timeframe, mitigating controls must be applied and residual risk formally assessed, recorded, and escalated where it exceeds risk appetite.

6.33. Mitigated risks are subject to continuous monitoring to ensure they remain within the Authority’s risk appetite. Digital Security and Security and Data Protection must continuously review threat intelligence to ensure accepted risks remain within acceptable tolerances given any changes in the threat landscape.

6.34. Emergency Re-evaluation: Upon the detection of new, highly virulent threats where IOCs are captured and logs recorded in an appropriate tool or an assessment on threat/proactive network blocks is disseminated via established IT service management workflows any relevant mitigated risks must be immediately voided and re-assessed by the Risk Owner. The “Act Now” protocol automatically supersedes prior risk acceptances when intelligence dictates imminent threat viability.

7. Accountabilities and responsibilities

7.1. The Authority chief security officer is the accountable owner of this policy.

7.2. The head of security policy is responsible for reviewing and maintaining this policy.

7.3. The line manager is responsible for taking the appropriate action where non-compliance to policy is identified - as detailed in the DWP Discipline Policy. 

7.4. The Authority Digital Function: The Authority’s Digital function is accountable for the operational execution of vulnerability management, CTEM, exposure discovery, risk triage, mitigation, and remediation activities. This includes facilitating and supporting the operational delivery of independent, external IT Health Checks (ITHCs). The Authority’s Digital function must ensure that vulnerabilities and security weaknesses identified through CTEM activities, vulnerability assessments, threat intelligence, and independent assurance activities are assessed and remediated in accordance with the DWP SS-027: Security Testing Standard and DWP SS-033: Patching and Exposure Management Standard.

7.5. The CRC is responsible for coordinating independent vulnerability assurance activities, maintaining visibility of departmental exposure, and consuming CTEM outputs to support threat intelligence, validation, assurance, and risk-informed decision-making.

7.6. Enterprise Security Risk Management (ESRM) is responsible for maintaining an overarching enterprise security assurance role. This includes collating, tracking, and providing visibility of ‘known issues’ derived from all forms of assurance activity (including ITHCs, Red Team operations, security incidents, and self-attestations) to inform holistic, enterprise-wide risk management.

7.7. Security Policy and Standards Team (SPST) is responsible for the authoring, maintenance, and strategic alignment of the TVCTEM Policy and supporting standards (for example DWP SS-027: Security Testing Standard and DWP SS-033: Patching and Exposure Management Standard), ensuring they reflect NCSC best practice and evolving threat landscapes.

7.8. Asset Owners (Engineering/Support): responsible for the permanent remediation (Elimination) of vulnerabilities within their digital services and maintaining service availability during mitigation.

8. Compliance

8.1. Everyone within the scope of this policy must adhere to all of the policy statements. Individual queries about implementing policies should be raised to the Security Advice Centre. If a business area is unable to comply with a policy statement, this must be raised to the Security Policy and Standards Team as soon as possible via the Security Policy Team, who will engage with teams to explore solutions.

8.2. The Authority defines a security incident as ‘the attempted or actual unauthorised access, use, disclosure, modification, loss, or destruction of an Authority asset in violation of security policy’. Where an individual is aware of a security incident, they must raise this immediately and be available to be contacted for further information so that the risk to Authority assets can be understood, controlled and resolved. Authority employees report security incidents via the Authority Security Incident Referral Webform. Third parties and suppliers must report security incidents by email (without delay) by using the Security Incident Report Form contained in appendix G of the DWP Security Incident Management Standard (SS-014), which must be sent to this mailbox: securityincident.responseteam-sirt@dwp.gov.uk.

8.3. Failure to report a security incident, potential or otherwise, could result in disciplinary action and, in the most severe circumstances, result in dismissal.

8.4. The Authority’s Security and Data Protection Team will regularly assess compliance with this policy and may need to inspect physical locations, technology systems, design and processes and speak to people to facilitate this. All Authority employees, agents, contractors, consultants, business partners and service providers will be required to facilitate, support, and when necessary, participate in any such inspection.

8.5. Individual System Owners are responsible for ensuring that their systems comply with relevant policies and standards. To verify this, System Owners must commission activities such as:

• assessing the effectiveness of controls through tests performed by first-line teams and second line activities (for example, security testing teams)

• independent external audit (third line) and IT Health Checks

8.6. For a new project, where vulnerability management and technical remediation cannot be carried out in compliance with the requirements of this policy, this must be presented to an assigned Authority / Digital Security Risk Manager or Security Architect, who will inform the Risk Owner. If necessary, the mitigation risk assessment will be considered as part of the project submission to the Authority’s Digital Design Authority (DDA) advisory or governance board.

8.7. For existing systems and services, the issue must be raised with an assigned Authority who must inform the Risk Owner. If necessary and appropriate, an exception must be sought from the Authority Standards Review Group.

8.8. All Authority organisations must be resilient to known vulnerabilities and attack methods by 2030.

8.9. All underlying vulnerability management processes, automated platforms, and manual assurance activities executed under this policy must remain compliant with the Authority’s GovAssure framework and established NCSC guidelines.

9. References

CIS Critical Security Controls Version 8.1 (cisecurity.org)

IT Asset Management (nist.gov)

DWP SS-014: Security Incident Management Standard

DWP SS-027: Security Testing Standard

DWP SS-033: Patching & Exposure Management Standard

Version Control (Changes From Previous Published Version)

Paragraph	Changes made and reason
Whole policy	The policy has been updated to move the authority towards exposure management at pace adopting Continuous Threat Exposure Management.
Scope	The Overview section has been removed and replaced with a simplified Introduction (Section 1) and Purpose (Section 2) aligned to the current Authority policy template. This removes explicit CTEM transition narrative, hybrid model context, and linkage to the DWP SS-033: Patching and Exposure Management Standard, simplifying the document structure but reducing strategic and audit traceability context.
Definitions – Reduction	Several definitions previously included have been removed, specifically: 10.1. Adversarial Exposure Validation, 10.2. Manual Posture Attestation, 10.3. Hybrid Operational Model, 10.4. Act Now Protocol. This simplifies the Definitions section but removes explicit descriptions of key CTEM components, creating reliance on external standards or implicit understanding where these terms are still referenced.
Terminology update	Updates the terminology section for the new security policy template. The material content has not changed only it’s format.
Statement 6.1	Revised statement to include independent external assurance in line with SS-027: Security Testing Standard.
Statement 6.3	A new statement added to include a proactive exposure reduction control aligned with CTEM.
Statement 6.13	The statement has been strengthened to include explicit access control mechanisms: 10.5. Addition of MFA, 10.6. Addition of PAM, 10.7. Addition of IP/Geo allow-listing. This replaces example-based controls (for example VLANs/bastions) with specific identity and access control requirements, improving enforceability and alignment with modern privileged access standards.
Statement 6.18	Added to link CTEM exposure management with incident response processes and addresses potential compromise scenarios.
Statement 6.20 and Statement 6.29	Removed timescales within the current policy instead pointing towards those within the security standard to allow for technical security exceptions to progress.
6.20	Specifically addresses technical vulnerabilities linking to the DWP SS-033: Patching and Exposure Management Standard following from further information which was provided.
6.21 - Everything else move down 1	A new addition which addresses security weaknesses as opposed to technical vulnerabilities which have been discovered during independent checking.
Accountabilities and Responsibilities	A series of new accountability statements introduced in addition to updating this section for the new security template: head of security policy (new role accountability), 10.8. line managers (responsibility for staff compliance), 10.9. The Authority Staff & Contractors (explicit compliance responsibility).
Statement 7.5	Revised statement for The Authority’s Digital in line with the requirement to engage with independent testing and that identified vulnerabilities are assessed and remediated in line with SS-027: Security Testing Standard.
Statement 7.6	CRC to facilitate the independent testing whereas SPST are responsible for the policy and standards creation.
Statement 7.7	Updates to reflect that SPST are only responsible for the authoring, maintenance and strategic alignment of the TVCTEM policy.
Compliance	Section updated to the new security policy template in addition to including: 10.10. Explicit escalation route to Security Advice Centre; 10.11. Formal route to Security Policy and Standards Team; 10.12. Strengthened incident reporting obligations; 10.13. Expanded participation requirements in assurance activity.