Vulnerability management policy

1. Purpose

This policy defines how HLD Group identifies, assesses, prioritises, and remediates vulnerabilities across its systems, applications, and dependencies. A disciplined vulnerability management programme reduces the window of exposure between the disclosure of a weakness and its remediation.

2. Scope

This policy applies to all production and corporate systems, applications, container images, infrastructure-as-code, and third-party dependencies used by HLD Group.

3. Definitions

• Vulnerability — a weakness that could be exploited to compromise confidentiality, integrity, or availability
• CVSS — the Common Vulnerability Scoring System used to rate severity
• Software composition analysis (SCA) — analysis of third-party and open-source dependencies for known vulnerabilities
• Penetration test — an authorised simulated attack to find exploitable weaknesses
• Remediation — fixing a vulnerability; mitigation — reducing its risk pending a fix

4. Identification

• Recurring authenticated vulnerability scanning of infrastructure and hosts
• Static and dynamic application security testing in the development pipeline
• Software composition analysis of dependencies, with alerting on newly disclosed vulnerabilities
• Container and image scanning before deployment
• Periodic independent penetration testing of key services
• Intake of reports through the Responsible Disclosure Policy

5. Risk-based prioritisation

Vulnerabilities are prioritised using severity, exploitability, exposure, and business context, not by CVSS score alone. Known exploited vulnerabilities and internet-facing exposure raise priority.

6. Remediation timeframes

• Critical: remediate or mitigate within 7 days, and faster for actively exploited internet-facing issues
• High: within 30 days
• Medium: within 90 days
• Low: within 180 days or by risk acceptance
• Timeframes may be shortened by customer contract or regulatory requirement

7. Exceptions and risk acceptance

Where a vulnerability cannot be remediated within its timeframe, a documented risk acceptance with compensating controls and an expiry date is required, approved by the CISO or delegate and recorded in the risk register.

8. Verification and metrics

• Fixes are verified by re-scan or re-test before closure
• Metrics on time-to-remediate, backlog age, and recurrence are reported to leadership
• Trends inform improvements to secure development and patching

9. Framework alignment

• ISO/IEC 27001:2022 Annex A control 8.8 (management of technical vulnerabilities)
• NIST SP 800-53 Rev. 5 control RA-5 (vulnerability monitoring and scanning) and SI-2 (flaw remediation)
• SOC 2 Trust Services Criteria CC7.1
• PCI DSS v4.0 Requirements 6 and 11 where cardholder data is in scope

10. Roles, exceptions, and review

This programme is owned by the security function under the CISO, with remediation owned by system and application owners. This policy is reviewed at least annually.